News for hackers. Stuff that matters.
Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by lispm on Thursday March 23, 2017 @01:01PM (#13941630)
GNU Emacs Lisp code is certainly not native - not until a JIT will be widespread. GNU Emacs usually compiles Lisp code to a byte code which is interpreted by a byte code engine written in C.

If you use a Common Lisp based editor like Clozure CL, Allegro CL and LispWorks have, they don't use a C-based byte code interpreted. The Lisp code is compiled directly to native code. Which makes editor extensions running in natively compiled Lisp code.

The advantage of the c-based byte code engine is compact code and improved portability - since the C compiler will already be provided with most platforms, whereas a native Lisp compiler is typically not something provided by a platform (CPU/OS/...) vendor...

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by gmfawcett on Thursday March 23, 2017 @01:12PM (#13941740)
I should be more clear. I don't think that just because Emacs contains an Elisp interpreter, we should call it a "non-native" application -- even if Elisp is integral to Emacs' operation.

If forced, I would say that Emacs-the-platform is native, and Emacs the system of Editor MACroS is not, since the macros run on the Emacs platform. But it seems kind of pedantic.

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by klibertp on Thursday March 23, 2017 @06:19PM (#13944863)
> I don't think that just because Emacs contains an Elisp interpreter,

The number of lines of Elisp my Emacs uses (counting plugins, but also built-ins) is actually more than twice the number of lines of C.

It's not that "Emacs contains an interpreter", rather it's "Emacs has all these features written in Elisp [...a looong list here...] Oh, and it also has an interpreter to execute it all".

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by lispm on Thursday March 23, 2017 @01:48PM (#13942164)
The Lisp code is not natively executed.

Some features like memory management (garbage collection) are layered on top of the OS.

The UI is not 'native' - it's based on a portable substrate written in C/Lisp, which works both on WIMP and terminal systems.

The user interaction is not native (commands, buffers, undo, preference dialogs, window/frames, ...).

etc.etc.

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by gmfawcett on Thursday March 23, 2017 @05:40PM (#13944612)
I never said the Lisp code was natively executed. I'm not sure where you got that idea.

Let's just agree to disagree. We are talking past each other at this point. Best regards!

Re:VS Code uses 13% CPU when idle due to blinking cursor ren... by kazinator on Thursday March 23, 2017 @07:20PM (#13945251)
I think that the definition of "native" should take into account how the code interacts with the system.

Because compiling code to the native instruction set shouldn't affect the semantics: so why should that be the only yard-stick for "native", right?

What is semantically relevant is: how much of the platform is exposed to the programs directly, versus through abstractions.

Suppose a language like Emacs Lisp or Java or whatever has only thin wrappers around POSIX through which applications interact with the platform. Then those programs are quasi-native POSIX programs, really. They are doing things like fork, waitpid, dup2 and whatever almost directly. And suppose that in the Windows version of that language, programs use functions that mimic CreateProcess or WaitForSingleObject. Then, regardless of the language being interpreted, it's really a native programming language.