ltsBlog

A few months ago, I ran into an issue with Emacs that I just found the solution to. In Emacs term-mode (or ansi-term, or multi-term), hitting Enter doesn’t work, and the mini-buffer displays Wrong type argument: characterp, return, and the term doesn’t see the keystroke.

I dented about it on identi.ca, and no one was able to help me. This turned out to be a mistake, because I kept seeing the dent as I Googled/DuckDuckGo’ed for a solution.

Anyway, I finally found the solution on the Korean blog Seorenn SIGSEGV.

The problem is basically that autopair had remapped the return key to an autopair function, which didn’t jive with term-mode. At least, that’s what Seorenn said.

If it were that simple, I would have noticed it when I installed autopair. Only in some environments does the problem manifest. For example, on Ubuntu, where I started using autopair, the problem never appears. When I switched to Fedora (and later Parabola), I figured it was some issue with the X server, because it worked fine when running in a terminal.

Now knowing that the problem was related to autopair, I can’t figure out how it ever worked.

Anyway, the fix is to add the following to your .emacs:

(add-hook 'term-mode-hook
  #'(lambda () (setq autopair-dont-activate t)))

(Code segment from emacs-fu, via Seorenn SIGSEGV.)

I found this awesome blog post on the Korean blog Seorenn SIGSEGV.

Using Google translate, I was able to extract the information I needed. However, Google translate quite botched it, as did Yahoo and Bing translate. I’ve used a combination of these three tools, and my understanding of Emacs, to put together a more reasonable translation.

I’m posting the full English text of it here because this is a problem I’ve had, and would like to help others find the solution. I don’t mean to rip off the original author, his blog seems quite good, worth reading, if you don’t mind poor translations (or, can read Korean).

The original post can be found here here.

In Emacs term-mode (M-x term) and multi-term-mode pressing the Enter key causes an error to appear in the mini-buffer, and the keystroke appears to have been eaten.

This problem only occurs when using autopair. are thought to In addition to or RET (Enter) as a separate feature for all modes of binding may also occur. if autopair the last of the solution are presented.

See below sum up shoveling machine.

Issue

During term-mode RET does not work. The mini-buffer shows the error message Wrong type argument: characterp, return. RET has been bound to something here, or maybe you saw the state I had a feeling heard nil.

Alternative

Fortunately, I was able to replace the RET key with C-j. This is used as a temporary measure to work with.

Cause Analysis

In term-mode use C-h k to find the function that RET is bound to. autopair that certain functions were bound.

As a result, be sure that autopair is the culprit.

Attempted Solution

In term-mode C-h k with C-j to determine the function bound to: term-send-raw.

In conclusion, I believe you will solve the problem in the RET key bindings by using define-key to bind the key to term-send-raw in term-mode-map.

But the code encounters an error. Is not allowed to do something it felt like.

Solution

The code below. Not two lines were able to solve it.

(add-hook 'term-mode-hook
  #'(lambda () (setq autopair-dont-activate t)))

Source of the above code: http://emacs-fu.blogspot.com/2010/06/console-apps-in-emacs-with-multi-term.html

This was originally posted to Facebook by me at 2010-08-02 23:20.

Note: For purposes of anyone interested in this, pointers in Java are more commonly referred to as references, because everything in Java must have it’s own name (method vs. function). This makes operating the Google DuckDuckGo machine easier. I wish I had known that when I wrote this.

In Java there are a few `primitive' datatypes, the rest of the datatypes are
implemented as classes.  They are:

byte
short
int
long
float
double
char
<pointer>

Normally, when declaring a primitive, you write the type of the primitive as
the variable type.  However, the reason I wrote pointer in brackets is that you
DON'T write pointer when declaring a variable storing a pointer.

For example, when I write
java.util.Stack stack = new java.util.Stack();
The variable stack does NOT store an object. It stores a /pointer/ to an object.
A pointer stores the memory address where a object is stored.

ALL VARIABLES STORE PRIMITIVES, IT IS IMPOSSIBLE TO STORE AN OBJECT.
For this reason, it is possible for the JVM to manage memory for you; it keeps
track of the pointers, and once there are no more pointers pointing to a
particular object, it can be deleted.

Why does this matter?  Well, consider that `String' is a class
(`java.lang.String'), not a primitive.  Consider the following code:

String str1 = "foo";
String str2 = "foo";
return (str1 == str2);

If String were a primitive, it would return true; but it returns false.
Strings are a little complex because they contain syntactic sugar.  Let's do
the same example with an integer instead:

Integer int1 = new Integer(5);
Integer int2 = new Integer(5);
return (int1 == int2);

The `java.lang.Integer' class is a class wrapper around the `int' primitive.
The `new' operator creates a class, and returns a pointer to it.  The source
code to the java.lang.Integer class contains the:
    private int value;

    public Integer(int val) {
        value = val;
    }

So, the above example generates to objects belonging to the java.lang.Integer
class.  Even though the .value's of the two objects are the same, they are
separate objects.  Therefore, int1 and int2 store two separate memory locations.
These two locations in the memory store the same data, but it is stored at both
locations.

The `==' operator takes two primitives, and compares their direct values.
Since int1 and int2 store two different memory locations, `(int1 == int2)'
evaluates to false.

Note: as pointed out by Ari Consul, everything following is false. The JVM does not copy the objects, it returns the pointer directly (no magic, as I’d suggested). The JVM will free() the object when there are no more pointers to it, via basic reference-counting

About copying objects:  when returning a private pointer, the JVM makes a copy
of the object that the pointer points to, and returns a pointer to the new
object, NOT the original pointer.

For example if I declare the method:

public static Integer getInt() {
    Integer val = new Integer(5);
    return val;
}

It does NOT actually return `val'; it returns a new pointer to a copy of the
object that val pointed to.

This was originally posted to Facebook by me at 2010-09-02 23:19. It was edited by me there 2010-07-03.

Java is an alright language. There are a lot of things it does right, but there
are a few things it doesn’t.

1. Distinction between classes and packages. I should be able to create
   sub-classes the same way as I add classes to a package; a package should
   just be an empty class.
2. Too many primitives. I should be able to (re-)construct more of the
   language.
3. No preprocessor/inlines. OO isn’t an excuse for this, make me do it at the
   class level (or rather, source file, not supporting `#include’ is fine). I
   should at least be able to add `#define int8=byte’ like in C. This
   wouldn’t be as much of an issue if all these things weren’t primitives; I
   could just do “public class int8 extends byte”. (yes, I could extend the
   `Byte’ class, but it wouldn’t come with all the syntactic sugar primitives
   get.)
4. Numbers: names. Yes the names used are long-standing convention in CS.
   These include some of the worst short-sighted mistakes in all of
   hackerdom… because they stuck. Yet, most reasonable languages can still
   support them, and sane equivalents.
   • byte -> int8
   • short -> int16
   • int -> int32
   • long -> int64
   • float -> float32
   • double -> float64

   This would easily be fixed if they weren’t all primitives (point 2), or if
   I had a preprocessor (point 3).

5. Numbers: unsigned. How about unsigned integers (uint16)? This would be
   easy to implement, if everything weren’t a damn primitive.
6. Give me an actual `struct’, like in C. I’m not asking for full manual
   memory management, just the ability to organize a chunk of it; you can
   still manage it for me. It would make serialization hellofalot
   easier.
7. It’s inconsistent about whether it uses the system encoding or it’s
   internal encoding. The String object just became worthless to anyone
   wanting to do any amount of I18N.
8. It’s internal encoding is junk. It maps UTF-16 symbols onto the `char’
   primitive, which is 16 bits.
   1. UTF-16 is junk, use UTF-8
   2. With any UTF encoding you must allow for a dynamic bit-length, for
      UTF-16 it’s 16-32 bits, UTF-8 is 8-32 bits

   I understand how/why it arrived at the solution it uses; at the time Java
   was designed, it was using UCS-2, which is a 16-bit encoding, and was
   superseded by UTF-16 in 1996 with Unicode 2.0. However, this is one of
   those things where you specify a new JVM version, and switch to UTF-8. You
   can even leave a legacy mode in the JVM that still uses UCS-2.

9. Octal prefix: `0′ is used as the prefix to specify an octal literal. Any
   third-grader can tell you why using a 0 as a prefix to a number is a bad
   idea; the number might just have padded zeros. Let’s look at the prefix
   used for hexadecimal: `0x’. This is great:
   1. It starts with a numeric character, which means that it must be a
      literal. If it started with an alphabetic character, it might be a
      variable name.
   2. The second character is a alphabetic character that is not used in
      any number system that is used in computer science. This allows it
      to serve a a unique identifier.

   Given these reasons, let’s think of a new prefix for octal… how about
   `0o’. That took literally less than 10 seconds for me to realize why `0′
   sucked, and to think of a better one.*

All-in-all, its still better than C++

* although, writing this gave me an even
better idea, but it would break `0x<value>’ for hex, which is incredibly
common among many languages:
`<base-in-decimal>x<value>’
so octal would be `8x<value>’
and hex would be `16x<value>’
It would be incredibly understandable, and, depending on implementation allow
simple arbitrary-base literals.

Well, I suppose just I’m only talking about Linux FUSE, I haven’t fiddled with FUSE on any other kernel. Anyway, FUSE screws with the idea of the root user:

$ ls
Makefile
build.log
...
$ sudo ls
ls: cannot open directory .: Permission denied
$ 

For those who don’t get it, the user with user ID `0′, usually with the username `root’ is the supreme administrator account — it is locked out of nothing, the kernel doesn’t even check file permissions when the user is root. The sudo (switch user do) command runs the following command as root. Anyway, even though the kernel doesn’t check file permissions when the user is root, FUSE does, in fact, it forces a umask of 0077, which means that even if the file permissions say “anyone logged in can read this file”, only the owner of the file can actually read it. I’m sure that this can be configured, but that doesn’t mean that it’s not brain damaged by default.