Giter VIP home page Giter VIP logo

remacs / remacs Goto Github PK

View Code? Open in Web Editor NEW
4.6K 4.6K 310.0 300.78 MB

Rust :heart: Emacs

License: GNU General Public License v3.0

Emacs Lisp 78.43% Makefile 0.29% C 18.20% Perl 0.12% Awk 0.04% Shell 0.18% Batchfile 0.01% HTML 0.14% C++ 0.18% M4 0.80% GDB 0.06% PostScript 0.22% TeX 0.79% SRecode Template 0.06% Smalltalk 0.07% JavaScript 0.08% NewLisp 0.08% Ruby 0.13% Slash 0.07% SystemVerilog 0.07%
editor emacs rust

remacs's Introduction

Rust โค๏ธ Emacs

This project isn't maintained anymore. If you are looking for a rust based emacs fork, you can take a look at emacs-ng. However this fork is not about replacing the C code base, but to provide additional features using the rich ecosystem of rust.

Join the chat at https://gitter.im/remacs-discuss/Lobby Build Status

A community-driven port of Emacs to Rust.

Table of Contents

Why Emacs?

Emacs will change how you think about programming.

Emacs is totally introspectable. You can always find out 'what code runs when I press this button?'.

Emacs is an incremental programming environment. There's no edit-compile-run cycle. There isn't even an edit-run cycle. You can execute snippets of code and gradually turn them into a finished project. There's no distinction between your editor and your interpreter.

Emacs is a mutable environment. You can set variables, tweak functions with advice, or redefine entire functions. Nothing is off-limits.

Emacs provides functionality without applications. Rather than separate applications, functionality is all integrated into your Emacs instance. Amazingly, this works. Ever wanted to use the same snippet tool for writing C++ classes as well as emails?

Emacs is full of incredible software concepts that haven't hit the mainstream yet. For example:

  • Many platforms have a single item clipboard. Emacs has an infinite clipboard.
  • If you undo a change, and then continue editing, you can't redo the original change. Emacs allows undoing to any historical state, even allowing tree-based exploration of history.
  • Emacs supports a reverse variable search: you can find variables with a given value.
  • You can perform structural editing of code, allowing you to make changes without breaking syntax. This works for lisps (paredit) and non-lisps (smartparens).
  • Many applications use a modal GUI: for example, you can't do other edits during a find-and-replace operation. Emacs provides recursive editing that allow you to suspend what you're currently doing, perform other edits, then continue the original task.

Emacs has a documentation culture. Emacs includes a usage manual, a lisp programming manual, pervasive docstrings and even an interactive tutorial.

Emacs has a broad ecosystem. If you want to edit code in a niche language, there's probably an Emacs package for it.

Emacs doesn't have a monopoly on good ideas, and there are other great tools out there. Nonetheless, we believe the Emacs learning curve pays off.

Why Rust?

Rust is a great alternative to C.

Rust has a fantastic learning curve. The documentation is superb, and the community is very helpful if you get stuck.

Rust has excellent tooling. The compiler makes great suggestions, the unit test framework is good, and rustfmt helps ensure formatting is beautiful and consistent.

The Rust packaging story is excellent. It's easy to reuse the great libraries available, and just as easy to factor out code for the benefit of others. We can replace entire C files in Emacs with well-maintained Rust libraries.

Code written in Rust easily interoperates with C. This means we can port to Rust incrementally, and having a working Emacs at each step of the process.

Rust provides many compile-time checks, making it much easier to write fast, correct code (even when using multithreading). This also makes it much easier for newcomers to contribute.

Give it a try. We think you'll like it.

Why A Fork?

Emacs is a widely used tool with a long history, broad platform support and strong backward compatibility requirements. The core team is understandably cautious in making far-reaching changes.

Forking is a longstanding tradition in the Emacs community for trying different approaches. Notable Emacs forks include XEmacs, Guile Emacs, and emacs-jit.

There have also been separate elisp implementations, such as Deuce, JEmacs and El Compilador.

By forking, we can explore new development approaches. We can use a pull request workflow with integrated CI.

We can drop legacy platforms and compilers. Remacs will never run on MS-DOS, and that's OK.

There's a difference between the idea of Emacs and the current implementation of Emacs. Forking allows us to explore being even more Emacs-y.

Getting Started

Requirements

  1. You will need Rust installed. The file rust-toolchain indicates the version that gets installed. This happens automatically, so don't override the toolchain manually. IMPORTANT: Whenever the toolchain updates, you have to reinstall rustfmt manually.

  2. You will need a C compiler and toolchain. On Linux, you can do something like:

     apt install build-essential automake clang libclang-dev
    

    On macOS, you'll need Xcode.

  3. Linux:

     apt install texinfo libjpeg-dev libtiff-dev \
       libgif-dev libxpm-dev libgtk-3-dev gnutls-dev \
       libncurses5-dev libxml2-dev libxt-dev
    

    macOS:

     brew install gnutls texinfo autoconf
    

    To use the installed version of makeinfo instead of the built-in (/usr/bin/makeinfo) one, you'll need to make sure /usr/local/opt/texinfo/bin is before /usr/bin in PATH. Mojave install libxml2 headers with: open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

Dockerized development environment

If you don't want to bother with the above setup you can use the provided Docker environment. Make sure you have docker 1.12+ and docker-compose 1.8+ available.

To spin up the environment run

docker-compose up -d

The first time you run this command, Docker will build the image. After that any subsequent startups will happen in less than a second. If this command fails because of needing absolute paths, make sure to set the PWD environment variable before calling the command like so:

PWD=$(pwd) docker-compose up -d

The working directory with remacs will be mounted under the same path in the container so editing the files on your host machine will automatically be reflected inside the container. To build remacs use the steps from Building Remacs prefixed with docker-compose exec remacs, this will ensure the commands are executed inside the container.

Building Remacs

$ ./autogen.sh
$ ./configure --enable-rust-debug
$ make

For a release build, don't pass --enable-rust-debug.

The Makefile obeys cargo's RUSTFLAGS variable and additional options can be passed to cargo with CARGO_FLAGS.

For example:

$ make CARGO_FLAGS="-vv" RUSTFLAGS="-Zunstable-options --cfg MARKER_DEBUG"

Running Remacs

You can now run your shiny new Remacs build!

# Using -q to ignore your .emacs.d, so Remacs starts up quickly.
# RUST_BACKTRACE is optional, but useful if your instance crashes.
$ RUST_BACKTRACE=1 src/remacs -q

Design Goals

Compatibility: Remacs should not break existing elisp code, and ideally provide the same FFI too.

Leverage Rust itself: Remacs should make best use of Rust to ensure code is robust and performant.

Leverage the Rust ecosystem: Remacs should use existing Rust crates wherever possible, and create new, separate crates where our code could benefit others.

Great docs: Emacs has excellent documentation, Remacs should be no different.

Progress

At this point we focus on porting lisp functions from C to Rust. Currently there are 642 functions in Rust and 823 in C (May 2019).

We have a progress section in our wiki and there's also a list of long-term goals under projects.

Porting Elisp Primitive Functions

The first thing to look at is the C implementation for the atan function. It takes an optional second argument, which makes it interesting. The complicated mathematical bits, on the other hand, are handled by the standard library. This allows us to focus on the porting process without getting distracted by the math.

The Lisp values we are given as arguments are tagged pointers; in this case they are pointers to doubles. The code has to check the tag and follow the pointer to retrieve the real values. Note that this code invokes a C macro (called DEFUN) that reduces some of the boilerplate. The macro declares a static variable called Satan that holds the metadata the Lisp compiler will need in order to successfully call this function, such as the docstring and the pointer to the Fatan function, which is what the C implementation is named:

DEFUN ("atan", Fatan, Satan, 1, 2, 0,
       doc: /* Return the inverse tangent of the arguments.
If only one argument Y is given, return the inverse tangent of Y.
If two arguments Y and X are given, return the inverse tangent of Y
divided by X, i.e. the angle in radians between the vector (X, Y)
and the x-axis.  */)
  (Lisp_Object y, Lisp_Object x)
{
  double d = extract_float (y);
  if (NILP (x))
    d = atan (d);
  else
    {
      double d2 = extract_float (x);
      d = atan2 (d, d2);
    }
  return make_float (d);
}

extract_float checks the tag (signalling an "invalid argument" error if it's not the tag for a double), and returns the actual value. NILP checks to see if the tag indicates that this is a null value, indicating that the user didn't supply a second argument at all.

Next take a look at the current Rust implementation. It must also take an optional argument, and it also invokes a (Rust) macro to reduce the boilerplate of declaring the static data for the function. However, it also takes care of all of the type conversions and checks that we need to do in order to handle the arguments and return value:

/// Return the inverse tangent of the arguments.
/// If only one argument Y is given, return the inverse tangent of Y.
/// If two arguments Y and X are given, return the inverse tangent of Y
/// divided by X, i.e. the angle in radians between the vector (X, Y)
/// and the x-axis
#[lisp_fn(min = "1")]
pub fn atan(y: EmacsDouble, x: Option<EmacsDouble>) -> EmacsDouble {
    match x {
        None => y.atan(),
        Some(x) => y.atan2(x)
    }
}

You can see that we don't have to check to see if our arguments are of the correct type, the code generated by the lisp_fn macro does this for us. We also asked for the second argument to be an Option<EmacsDouble>. This is the Rust type for a value which is either a valid double or isn't specified at all. We use a match statement to handle both cases.

This code is so much better that it's hard to believe just how simple the implementation of the macro is. It just calls .into() on the arguments and the return value; the compiler does the rest when it dispatches this method call to the correct implementation.

Contributing

Pull requests welcome, no copyright assignment required. This project is under the Rust code of conduct.

There's lots to do! We keep a list of low hanging fruit here so you can easily choose one. You can find information in the Porting cookbook or ask for help in our Gitter channel.

remacs's People

Contributors

acinnes avatar albinus avatar andreas-schwab avatar belanger avatar brotzeit avatar dgutov avatar dmantipov avatar drmirror avatar eggert avatar eli-zaretskii avatar holomorph avatar jave avatar larsmagne avatar lektu avatar leoliu avatar link0ff avatar loveshack avatar malabarba avatar mituharu avatar monnier avatar npostavs avatar paveljanik avatar rfrancoise avatar rgmorris avatar sam-s avatar snogglethorpe avatar wilfred avatar wohler avatar xfq avatar yamaoka avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

remacs's Issues

Compile Failure "...unexec: unrecognized section..." on MacOS El Capitรกn

Its my first try to compile Remacs, I follow the intruction but this problem I don't understand, I think is a version of packages in OS X.

--- List of All Regions ---
   address     size prot maxp
--- List of Regions to be Dumped ---
   address     size prot maxp
--- Header Information ---
Magic = 0xfeedfacf
CPUType = 16777223
CPUSubType = -2147483645
FileType = 0x2
NCmds = 28
SizeOfCmds = 4152
Flags = 0x00800085
Highest address of load commands in input file: 0x10085e000
Lowest offset of all sections in __TEXT segment:   0x2700
--- List of Load Commands in Input File ---
# cmd              cmdsize name                address     size
0 LC_SEGMENT_64          72 __PAGEZERO                0 0x100000000
1 LC_SEGMENT_64         952 __TEXT           0x100000000 0x29f000
                           __text           0x100002700 0x231c08
                           __stubs          0x100234308    0xc12
                           __stub_helper    0x100234f1c   0x142e
                           __const          0x100236350  0x2f930
                           __cstring        0x100265c80  0x1552b
                           __gcc_except_tab 0x10027b1ac   0x3778
                           __objc_methname  0x10027e924   0x3612
                           __objc_classname 0x100281f36    0x114
                           __objc_methtype  0x10028204a   0x1653
                           __unwind_info    0x1002836a0   0x3910
                           __eh_frame       0x100286fb0  0x18048
2 LC_SEGMENT_64        1672 __DATA           0x10029f000 0x403000
                           __nl_symbol_ptr  0x10029f000     0x10
                           __got            0x10029f010    0x278
                           __la_symbol_ptr  0x10029f288   0x1018
                           __const          0x1002a02a0   0xfcc0
                           __cfstring       0x1002aff60    0x880
                           __objc_classlist 0x1002b07e0     0x78
                           __objc_catlist   0x1002b0858      0x8
                           __objc_protolist 0x1002b0860     0x28
                           __objc_imageinfo 0x1002b0888      0x8
                           __objc_const     0x1002b0890   0x3bd0
                           __objc_selrefs   0x1002b4460   0x10c0
                           __objc_classrefs 0x1002b5520    0x218
                           __objc_superrefs 0x1002b5738     0x60
                           __objc_ivar      0x1002b5798    0x200
                           __objc_data      0x1002b5998    0x4b0
                           __data           0x1002b5e50 0x340fc8
                           __thread_vars    0x1005f6e18     0x90
                           __thread_data    0x1005f6ea8     0xc8
                           __bss            0x1005f6f70  0x89ac8
                           __common         0x100680a40  0x20791
3 LC_SEGMENT_64          72 __LINKEDIT       0x1006a2000 0x1bc000
4 LC_DYLD_INFO_ONLY      48
5 LC_SYMTAB              24
6 LC_DYSYMTAB            80
7 LC_LOAD_DYLINKER       32
8 LC_UUID                24
9 LC_VERSION_MIN_MACOSX      16
10 LC_SOURCE_VERSION      16
11 LC_MAIN                24
12 LC_LOAD_DYLIB          88
13 LC_LOAD_DYLIB          88
14 LC_LOAD_DYLIB          64
15 LC_LOAD_DYLIB          88
16 LC_LOAD_DYLIB          88
17 LC_LOAD_DYLIB          56
18 LC_LOAD_DYLIB          56
19 LC_LOAD_DYLIB          56
20 LC_LOAD_DYLIB          48
21 LC_LOAD_DYLIB         104
22 LC_LOAD_DYLIB         104
23 LC_LOAD_DYLIB          96
24 LC_LOAD_DYLIB          96
25 LC_LOAD_DYLIB          56
26 LC_FUNCTION_STARTS      16
27 LC_DATA_IN_CODE        16
0x101efc080 (sz:   0x3f24/  0x3f28)
0x101e00000 (sz:  0x1b4c5/ 0xfc080)
0x1018fc080 (sz:   0x3f24/  0x3f28)
0x101800000 (sz:  0xdcdca/ 0xfc080)
0x101dfc080 (sz:   0x3f24/  0x3f28)
0x101d00000 (sz:  0x439c5/ 0xfc080)
0x101cfc080 (sz:   0x3f24/  0x3f28)
0x101c00000 (sz:  0xe2d60/ 0xfc080)
0x1027f8000 (sz:   0x75e0/  0x7fa0)
0x102000000 (sz: 0x75bdff/0x7f8000)
0x107ff8000 (sz:   0x16b6/  0x7fa0)
0x107800000 (sz: 0x1693fd/0x7f8000)
0x1077f8000 (sz:   0x1c86/  0x7fa0)
0x107000000 (sz: 0x1c63ff/0x7f8000)
0x106ff8000 (sz:   0x5eea/  0x7fa0)
0x106800000 (sz: 0x5ec7ff/0x7f8000)
0x100ca9000 (sz:        0/  0x1000)
--- Load Commands written to Output File ---
Writing segment __PAGEZERO       @        0 (       0/0x100000000 @          0)
Writing segment __TEXT           @        0 (0x29f000/0x29f000 @ 0x100000000)
Writing segment __DATA           @ 0x29f000 (0x403000/0x403000 @ 0x10029f000)
        section __nl_symbol_ptr  at 0x29f000 - 0x29f010 (sz:     0x10)
        section __got            at 0x29f010 - 0x29f288 (sz:    0x278)
        section __la_symbol_ptr  at 0x29f288 - 0x2a02a0 (sz:   0x1018)
        section __const          at 0x2a02a0 - 0x2aff60 (sz:   0xfcc0)
        section __cfstring       at 0x2aff60 - 0x2b07e0 (sz:    0x880)
        section __objc_classlist at 0x2b07e0 - 0x2b0858 (sz:     0x78)
        section __objc_catlist   at 0x2b0858 - 0x2b0860 (sz:      0x8)
        section __objc_protolist at 0x2b0860 - 0x2b0888 (sz:     0x28)
        section __objc_imageinfo at 0x2b0888 - 0x2b0890 (sz:      0x8)
        section __objc_const     at 0x2b0890 - 0x2b4460 (sz:   0x3bd0)
        section __objc_selrefs   at 0x2b4460 - 0x2b5520 (sz:   0x10c0)
        section __objc_classrefs at 0x2b5520 - 0x2b5738 (sz:    0x218)
        section __objc_superrefs at 0x2b5738 - 0x2b5798 (sz:     0x60)
        section __objc_ivar      at 0x2b5798 - 0x2b5998 (sz:    0x200)
        section __objc_data      at 0x2b5998 - 0x2b5e48 (sz:    0x4b0)
        section __data           at 0x2b5e50 - 0x5f6e18 (sz: 0x340fc8)
unexec: unrecognized section __thread_vars in __DATA segment
make[1]: *** [bootstrap-emacs] Error 1
make: *** [src] Error 2


Use Corrode

Corrode is a C to Rust translator. It wouldn't be able to translate everything.

Really I just want to know if anyone has tried this and if there are any reasons the project would choose not to use Corrode.

build of temacs fails on Fedora 24

make fails to build temacs on my fedora 24 laptop. I checked the dependencies(cairo, GIO/glib,pango) and I seem to have everything...

$ uname -a
Linux drpyser.localdomain 4.9.5-100.fc24.x86_64 #1 SMP Fri Jan 20 12:27:44 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ make
[...]
CCLD     temacs
/usr/lib64/libpangoft2-1.0.so.0: undefined reference to `pango_matrix_get_font_scale_factors'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `pango_attr_font_features_new'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `pango_renderer_set_alpha'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `cairo_surface_set_device_scale'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `g_list_model_get_n_items'
/usr/lib64/libpangoft2-1.0.so.0: undefined reference to `FcWeightToOpenType'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `pango_attr_background_alpha_new'
/usr/lib64/libpangoft2-1.0.so.0: undefined reference to `FcWeightFromOpenType'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `g_file_enumerator_iterate'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `g_param_spec_get_name_quark'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `g_strv_contains'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `pango_renderer_get_alpha'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `cairo_surface_get_device_scale'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `g_list_model_get_item'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `pango_attr_foreground_alpha_new'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/libgtk-3.so: undefined reference to `g_list_model_get_type'
collect2: error: ld returned 1 exit status
Makefile:631: recipe for target 'temacs' failed
make[1]: *** [temacs] Error 1
make[1]: Leaving directory '/home/drpyser/repositories/remacs/src'
Makefile:419: recipe for target 'src' failed
make: *** [src] Error 2

Can't commit in magit

(followup to #92)

When trying to commit staged changes in magit, the following error is produced:

Nothing staged (or unstaged)

In regular Emacs, this works correctly.

Unfortunately, I don't currently have a guess as to why this happens.

Remove SHA-224 API

I suggest removing the SHA-224 API completely. From searching the source code, it seems nothing actually uses it. Also #110 proposes switching to ring, which doesn't implement SHA-224 (because no real-world things use it, and because it is less secure than SHA-256, which is the minimum that people should be using these days).

Making "make clean" remove .elc files

This was listed in the Readme as a low-hanging fruit for contributing, so I'm going to take a crack at it!

Doing so will hopefully make it easier to spot bugs, because the old definitions in .elc files won't interfere when you recompile Remacs.

magit emacsclient

I'm just trying out remacs, and almost everything seems to work properly. The only issue I've noticed so far is that magit complains that it can't find emacsclient

     Warning (with-editor): Cannot determine a suitable Emacsclient
     Determining an Emacsclient executable suitable for the
      current Emacs instance failed.  For more information
      please see https://github.com/magit/magit/wiki/Emacsclient.

I'm using the Archlinux package distributed through the AUR, so it's possible this is a packing issue. Anyone else see this? If so, any solution or workarounds?

Run rustfmt on Travis CI

We should be running rusfmt on the backend and fail the build if the code isn't formatted properly.

Windows build is broken.

Hi, some recent changes broke windows build. Most are related to the MSDOS code removing - it accidentally broke some lines relating to WINDOWSNT case. Won't have time to look at it carefully before weekend. Just leave a issue here.

cargo build error on master

Hello everyone,

With the last update 69de1625 started to get following error:

$ cargo build --verbose
       Fresh lazy_static v0.2.2
       Fresh libc v0.2.17
   Compiling remacs v0.1.0 (file:///home/alex/dev/remacs/rust_src)
     Running `rustc build.rs --crate-name build_script_build --crate-type bin -g -C metadata=6ee1bca0c6881354 --out-dir /home/alex/dev/remacs/rust_src/target/debug/build/remacs-6ee1bca0c6881354 --emit=dep-info,link -L dependency=/home/alex/dev/remacs/rust_src/target/debug/deps --extern libc=/home/alex/dev/remacs/rust_src/target/debug/deps/liblibc-ad32fde1bd850538.rlib`
error: the crate `libc` is compiled with the panic strategy `abort` which is incompatible with this crate's strategy of `unwind`

error: aborting due to previous error

error: Could not compile `remacs`.

Caused by:
  process didn't exit successfully: `rustc build.rs --crate-name build_script_build --crate-type bin -g -C metadata=6ee1bca0c6881354 --out-dir /home/alex/dev/remacs/rust_src/target/debug/build/remacs-6ee1bca0c6881354 --emit=dep-info,link -L dependency=/home/alex/dev/remacs/rust_src/target/debug/deps --extern libc=/home/alex/dev/remacs/rust_src/target/debug/deps/liblibc-ad32fde1bd850538.rlib` (exit code: 101)

Do somebody have any ideas what's wrong here?

Regarding remacs goals and design decisions

I would like to clarify some of remac's design goals here.
I've been using and following the development of emacs for I guess eight years now, and while that tenure pales in comparison to many others I do have a clear understanding of emac's successes and failings.
For one thing, emacs LISP is not particularly fast even with when it's JIT'd.
One thing that needs to be clarified: are we required to preserve emac's bytecode?
I would like to argue against doing that.
One thing that would be nice is leveraging LLVM to compile emac's lisp into bitcode, which can also be JIT'd or AOT'd. The difference here is that we can discard emac's slow bytecode which uses a stack machine for a more efficient closer-to-the-machine format.
It also allows us to be completely language agnostic. Obviously we want to preserve compatibility with emacs lisp but now we can separate our concerns a little better. Remacs could include a FFI and a emacs lisp compiler AND a number of other compilers such as for Scheme or any language that has a compiler to LLVM.
Another problem that comes up here is how closely aligned this project is to the philosophical goals of the emacs and larger GNU project. One long standing argument in the emacs-dev list is that people writing emacs extensions would really like to have the AST for whatever language they are inspecting. For C, that would mean using GCC as some sort of plug-in since GCC is already part of the GNU project. But RMS does not want GCC to be open like that so development for more syntactic aware extensions is at a stalemate. If we ignore the philosophical ideals of emacs we can simply use LLVM or other tools that are not GPL licensed.
I hope that by answering these questions we can clarify the design goals of remacs slightly.

Discussion forum/IRC channel?

GitHub Issues isn't a great platform to discuss major features or ask questions, so it might not be a bad idea to set up another forum/IRC channel for that sort of discussion.

Document libxml2 as a build dependency

It looks like it's not finding the libxml2 headers. I've never compiled Emacs rust or otherwise, so not sure what the best fix is.

~/C/E/remacs git:master โฏโฏโฏ uname -a
Darwin galadriel.local 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64
~/C/E/remacs git:master โฏโฏโฏ gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
~/C/E/remacs git:master โฏโฏโฏ make
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C lib all
  GEN      alloca.h
  GEN      byteswap.h
  GEN      c++defs.h
  GEN      arg-nonnull.h
  GEN      warn-on-use.h
  GEN      dirent.h
  GEN      fcntl.h
  GEN      getopt.h
  GEN      inttypes.h
  GEN      signal.h
  GEN      stdint.h
  GEN      stdio.h
  GEN      stdlib.h
  GEN      string.h
  GEN      sys/select.h
  GEN      sys/stat.h
  GEN      sys/time.h
  GEN      sys/types.h
  GEN      time.h
  GEN      unistd.h
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
  CC       acl-errno-valid.o
  CC       acl-internal.o
  CC       get-permissions.o
  CC       set-permissions.o
  CC       allocator.o
  CC       binary-io.o
  CC       c-ctype.o
  CC       c-strcasecmp.o
  CC       c-strncasecmp.o
  CC       careadlinkat.o
  CC       close-stream.o
  CC       count-one-bits.o
  CC       count-trailing-zeros.o
  CC       md5.o
  CC       sha1.o
  CC       sha256.o
  CC       sha512.o
  CC       dtoastr.o
  CC       dtotimespec.o
  CC       filemode.o
  CC       gettime.o
  CC       pipe2.o
  CC       qcopy-acl.o
  CC       stat-time.o
  CC       strftime.o
  CC       timespec.o
  CC       timespec-add.o
  CC       timespec-sub.o
  CC       u64.o
  CC       unistd.o
  CC       utimens.o
  CC       openat-die.o
  CC       save-cwd.o
  CC       acl_entries.o
  CC       fpending.o
  CC       fstatat.o
  CC       getopt.o
  CC       getopt1.o
  CC       lstat.o
  CC       memrchr.o
  CC       mktime.o
  CC       openat-proc.o
  CC       readlink.o
  CC       readlinkat.o
  CC       sig2str.o
  CC       stat.o
  CC       symlink.o
  CC       time_rz.o
  CC       timegm.o
  AR       libgnu.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libgnu.a(u64.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libgnu.a(unistd.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libgnu.a(u64.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: libgnu.a(unistd.o) has no symbols
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C lib-src all
  CC       regex.o
  CCLD     etags
  CCLD     ctags
  CCLD     emacsclient
  CCLD     ebrowse
  CCLD     profile
  CC       pop.o
  CCLD     movemail
  CCLD     hexl
  CCLD     update-game-score
  CCLD     make-docfile
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C src VCSWITNESS='$(srcdir)/../.git/logs/HEAD' all
  GEN      globals.h
  CC       dispnew.o
  CC       frame.o
  CC       scroll.o
  CC       xdisp.o
  CC       menu.o
  CC       window.o
  CC       charset.o
  CC       coding.o
  CC       category.o
  CC       ccl.o
  CC       character.o
  CC       chartab.o
  CC       bidi.o
  CC       cm.o
  CC       term.o
  CC       terminal.o
  CC       xfaces.o
  CC       emacs.o
  CC       keyboard.o
keyboard.c:75:33: warning: unknown warning group '-Wclobbered', ignored [-Wunknown-pragmas]
# pragma GCC diagnostic ignored "-Wclobbered"
                                ^
1 warning generated.
  CC       macros.o
  CC       keymap.o
  CC       sysdep.o
  CC       buffer.o
  CC       filelock.o
  CC       insdel.o
  CC       marker.o
  CC       minibuf.o
  CC       fileio.o
  CC       dired.o
  CC       cmds.o
  CC       casetab.o
  CC       casefiddle.o
  CC       indent.o
  CC       search.o
  CC       regex.o
  CC       undo.o
  CC       alloc.o
  CC       data.o
  GEN      buildobj.h
  CC       doc.o
  CC       editfns.o
  CC       callint.o
  CC       eval.o
  CC       floatfns.o
  CC       fns.o
  CC       font.o
  CC       print.o
  CC       lread.o
  CC       syntax.o
  CC       unexmacosx.o
  CC       bytecode.o
  CC       process.o
  CC       gnutls.o
  CC       callproc.o
  CC       region-cache.o
  CC       sound.o
  CC       atimer.o
  CC       doprnt.o
  CC       intervals.o
  CC       textprop.o
  CC       composite.o
  CC       xml.o
xml.c:23:10: fatal error: 'libxml/tree.h' file not found
#include <libxml/tree.h>
         ^
1 error generated.
make[1]: *** [xml.o] Error 1
make: *** [src] Error 2

Progress indicator in README

It'd be awesome to have a high-level overview of how much is done in the README for folks that are just watching this project :)

Ensure we handle USE_LSB_TAG correctly

In some Rust code we're assuming that it's always 1. Our comments say this too, which misleads new contributors.

We should define it as a constant and ensure we handle both the true and false case.

Support for guile as the scripting language

Hii @remacs team.

I am completely awed by this work - thanks for making emacs ultra-awesome ๐Ÿ˜„

I was wondering if support for guile as the scripting language is planned? GuileEmacs seems to under development for quite some time now and they've taken care than it can compile most of elisp code as it is. Now that remacs is in spirit of emacs-extensibility, I think it'd be great if all the effort in Guile can be brought fruition in remacs.

I think this would be a huge boost since it'd essentially add support for lua , ecmascript and emacslisp and many other languages as mentioned in the GNU Guile documentation

Let me know about how can I help regarding guile integration ๐Ÿ‘

I'll post the relevant links here

error[E0512]: transmute called with differently sized types: *const libc::c_void (32 bits) to lisp::LispMisc (64 bits)

michael@Three:~/src/remacs/rust_src$ cargo build
Compiling lazy_static v0.2.2
Compiling libc v0.2.17
Compiling remacs v0.1.0 (file:///home/michael/src/remacs/rust_src)
error[E0512]: transmute called with differently sized types: *const libc::c_void (32 bits) to lisp::LispMisc (64 bits)
--> src/lisp.rs:465:14
|
465 | unsafe { mem::transmute(XUNTAG(a, LispType::Lisp_Misc)) }
| ^^^^^^^^^^^^^^ transmuting between 32 bits and 64 bits

error[E0512]: transmute called with differently sized types: lisp::LispMisc (64 bits) to *const lisp::LispMiscAny (32 bits)
--> src/lisp.rs:471:14
|
471 | unsafe { mem::transmute(XMISC(a)) }
| ^^^^^^^^^^^^^^ transmuting between 64 bits and 32 bits

error[E0512]: transmute called with differently sized types: lisp::LispMisc (64 bits) to *const marker::LispMarker (32 bits)
--> src/lisp.rs:500:14
|
500 | unsafe { mem::transmute(XMISC(a)) }
| ^^^^^^^^^^^^^^ transmuting between 64 bits and 32 bits

error: aborting due to 3 previous errors

error: Could not compile remacs.

About unexec feature

Is unexec() feature a must to have in Remacs?

I think is quite old and supporting it would be very hard because we would need to maintain the emacs malloc implementation because support for unexec is being removed from glibc.

Also there is a lot of support code for other platforms that makes the project itself more complex because it makes more easily to break things.

Disadvantages

  • Remacs will load slower.
  • It will take some time to find a solution to the problem of slow loading.

Advantages

  • Clean code ๐Ÿ‘
  • It makes more easy to port functions related to memory management to Rust.

Implement cons

This will require some allocation work.

DEFUN ("cons", Fcons, Scons, 2, 2, 0,
       doc: /* Create a new cons, give it CAR and CDR as components, and return it.  */)
  (Lisp_Object car, Lisp_Object cdr)
{
  register Lisp_Object val;

  MALLOC_BLOCK_INPUT;

  if (cons_free_list)
    {
      /* We use the cdr for chaining the free list
	 so that we won't use the same field that has the mark bit.  */
      XSETCONS (val, cons_free_list);
      cons_free_list = cons_free_list->u.chain;
    }
  else
    {
      if (cons_block_index == CONS_BLOCK_SIZE)
	{
	  struct cons_block *new
	    = lisp_align_malloc (sizeof *new, MEM_TYPE_CONS);
	  memset (new->gcmarkbits, 0, sizeof new->gcmarkbits);
	  new->next = cons_block;
	  cons_block = new;
	  cons_block_index = 0;
	  total_free_conses += CONS_BLOCK_SIZE;
	}
      XSETCONS (val, &cons_block->conses[cons_block_index]);
      cons_block_index++;
    }

  MALLOC_UNBLOCK_INPUT;

  XSETCAR (val, car);
  XSETCDR (val, cdr);
  eassert (!CONS_MARKED_P (XCONS (val)));
  consing_since_gc += sizeof (struct Lisp_Cons);
  total_free_conses--;
  cons_cells_consed++;
  return val;
}

CC nsterm.m gives 148 macos12 deprecation warnings

  CC       nsterm.o
nsterm.m:233:8: warning: 'NSNumericPadKeyMask' is deprecated: first deprecated in macOS 10.12 [-Wdeprecated-declarations]
  0x41|NSNumericPadKeyMask,     0xAE,  /* KP_Decimal */
       ^~~~~~~~~~~~~~~~~~~
       NSEventModifierFlagNumericPad
/System/Library/Frameworks/AppKit.framework/Headers/NSEvent.h:186:35: note: 'NSNumericPadKeyMask' has been explicitly marked deprecated here
static const NSEventModifierFlags NSNumericPadKeyMask         API_DEPRECATED_WITH_REPLACEMENT("NSEventModifierFlagNumericPad", macosx(10.0, 10.12)) = NSEven...
                                  ^
[ *snip* ]
148 warnings generated.

Looks like this patch from the non-Rust version is required.

Similarly, nsfns.m gives 6 warnings and nsmenu.m gives 11 warnings

Port tempname to Rust

We could straightforwardly replace gen_tempname and try_tempname with Rust implementations, probably from an existing crate.

This would let us remove tempname.c entirely.

Write a CONTRIBUTING.md

We should cover:

  • a suggestion to file a bug to avoid multiple people working on the same thing
  • what's required to contribute (write a PR, tests where possible, no warnings)
  • review requirements (needs a review, anyone in the list)
  • a note on backwards compatibility (we shouldn't break it)

Linking libraries issue

Sorry i'm not very familiar with the auto{conf, ...} thing. But i hope someone who is more familiar with them can fix it.

The problem itself is very clear:
Under windows the generated rust static library have 5 dependency libraries, three of them already linked but two not, namely -lws2_32 -luserenv. The cargo build can correctly displays this information on the screen. However the emacs linking doesn't have these flags. I think it needs to modified to either add these libraries on Windows platform or detect cargo output and do something.

Building on mac fails

Hi,

I followed the instruction and tried to build the project. Unfortunately, the project build fails for me. Could you help me to sort it out?

^
4 warnings generated.
  CC       terminfo.o
  CC       lastfile.o
RUSTFLAGS= \
	cargo build  --manifest-path ../rust_src/Cargo.toml
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading lazy_static v0.2.2
 Downloading libc v0.2.17
   Compiling alloc_unexecmacosx v0.1.0 (file:///Users/kirill/develop/remacs/rust_src/alloc_unexecmacosx)
   Compiling lazy_static v0.2.2
   Compiling libc v0.2.17
error[E0554]: #[feature] may not be used on the stable release channel
 --> /Users/kirill/develop/remacs/rust_src/alloc_unexecmacosx/src/lib.rs:1:1
  |
1 | #![feature(allocator)]
  | ^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

Build failed, waiting for other jobs to finish...
error: Could not compile `alloc_unexecmacosx`.

To build it I run

$ ./autogen.sh
$ ./configure --enable-rust-debug --without-makeinfo
$ make

Thoughts on porting the regex engine

Hi there,

This is a cool project! There was recently some discussion about changing Emacs' regex engine, so I thought I'd post the link here. The TL;DR is that a major difficulty lies in Emacs' use of a gap buffer, a structure that few regex-parsing libraries support.

Good luck!

RFC: Use Rust codegen

About the use of Rust codegen

Description

I've thinked that we could use nigthtly Rust features to make Remacs
development and porting easier. I was inspired how the rocket.rs crate
handled the HTTP request using Rust attributes, it looks something like this:

#[get("/")]
fn index() -> &'static str {
   "Hello, world!"
}

I think Remacs could do something similar and have a defun or a
lisp_function attribute to generate FFI code, also it would solve the problem
of having two lisp object types, because the generated code can hide all the
details of having a FFI Lisp_Object type.

An example of a native lisp function would look like this in Rust:

#[lisp_function(name = "symbolp", min = 1)]
#[lisp_doc("Return t if OBJECT is a symbol")]
#[lisp_doc("(fn OBJECT)")]
fn symbolp(object: LispObject) -> LispObject {
    if object.is_symbol() {
        LispObject::constant_t()
    } else 
        LispObject::constant_nil()
    }
}

And the generated code would look something like this:

lazy_static! {
    pub static ref Ssymbolp: remacs_sys::Lisp_Subr = remacs_sys::Lisp_Subr {
        header: VectorlikeHeader {
            size: ((lisp::PvecType::PVEC_SUBR as libc::c_int) << lisp::PSEUDOVECTOR_AREA_BITS) as libc::ptrdiff_t,
        },
        function: Fsymbolp as *const libc::c_void,
        min_args: 1,
        max_args: 1,
        symbol_name: b"symbolp\0".as_ptr(),
        intspec: std::ptr:null(),
        doc: b"Return t if OBJECT is a symbol\n(fn OBJECT)".as_ptr(),
    }
}

pub extern "C" Fsymbolp(p0: remacs_sys::Lisp_Object) -> remacs_sys::Lisp_Object {
    let p0 = LispObject::from_raw(p0);
    let ret = symbolp(p0);
    ret.to_raw()
}

fn symbolp(object: LispObject) -> LispObject {
    if object.is_symbol() {
        LispObject::constant_t()
    } else 
        LispObject::constant_nil()
    }
}

You will notice that there is an extra type in the Fsymbolp function, this is
used to keep the ABI compability with the C code.

Implementation

First there are some requeriments for a function to use the attribute, first all of it's parameters and the return types must be a LispObject. Also the parameter limit is 6, because that is how Lisp_Subr is defined in C.

Also i think it would be good to hve the FFI code in a separate crate (maybe called remacs-sys) to decouple the FFI code.

On the rustc side i don't know how this could be done, some research needs to be made to make this possible on the Rust compiler side.

Advantages

  • It hides a lot of the FFI.
  • Clean code.
  • It will be more hard to make mistakes.
  • Builds on Travis CI will be more faster because we don't need additional versions.

Disadvantages

  • This will require the use of nightly Rust, however we now are using it on
    Mac OS X builds so this should be no problem.
  • It will be a bit more difficult to debug because an extra call is made.
  • The Rust nightly compiler API is unstable, it changes a lot, we will need to
    stick to a specific nightly version and update the codegen code when a breaking
    change happens on the rustc side.

Alternatives

  • Leave it as is.
  • Wait for Rust to have an stable API for code generation.

My opinion

Having this feature is worth it because if the project needs to be cleaned up
this is the way to go.

UPDATE: min parameter is used to specify the minimum parameters the function
has, and the maximum is calculated.

make on OSX is broken: `emacs: Invalid function cdr`

Steps before the error:

./autogen.sh
/configure --without-makeinfo
brew install gnutls
make

Error produced

mv -f remacs bootstrap-emacs
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
  GEN      calendar/cal-loaddefs.el
emacs: Invalid function: cdr
make[2]: *** [calendar/cal-loaddefs.el] Error 1
make[1]: *** [bootstrap-emacs] Error 2
make: *** [src] Error 2

Environment

  • OSX Sierra 10.12.2 (16C67)
  • GNU Make 3.81
  • Darwin 16.3.0 Darwin Kernel Version 16.3.0: Thu Nov 17 20:23:58 PST 2016; root:xnu-3789.31.2~1/RELEASE_X86_64 x86_64
  • xcode-select version 2347

make_natnum(marker_position(x) as i64) >expected i32, found i64

Hi,

Windows 10, latest Rust version installed I run into the arch problem but don't know really why?!

[C:\workspace\rust\Projekte\remacs-master\rust_src]cargo build
Compiling lazy_static v0.2.2
Compiling libc v0.2.17
Compiling remacs v0.1.0 (file:///C:/workspace/rust/Projekte/remacs-master/rust_src)
error[E0308]: mismatched types
--> src\lisp.rs:316:21
|
316 | make_natnum(marker_position(x) as i64)
| ^^^^^^^^^^^^^^^^^^^^^^^^^ expected i32, found i64

error: aborting due to previous error

error: Could not compile remacs.

To learn more, run the command again with --verbose.

Linux 32 bits build is broken

Debug:

Starting program: /home/jeandudey/rust-projects/remacs/src/temacs --batch --loadup bootstrap
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0822d1b2 in remacs::lists::XCAR (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:151
151	    (*XCONS(object)).car
(gdb) bt
#0  0x0822d1b2 in remacs::lists::XCAR (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:151
#1  0x0822d291 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:166
#2  0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#3  0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#4  0x081aaa2c in Ferror_message_string (obj=140488155) at print.c:868
#5  0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140488155, data@entry=140488139, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#6  0x0818fb82 in Fsignal (error_symbol=26328, data=140488139) at eval.c:1483
#7  0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#8  0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073749392, arg2=16056) at eval.c:1624
#9  0x0817b0e5 in wrong_type_argument (predicate=-1073749392, value=16056) at data.c:152
#10 0x0822d310 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:170
#11 0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#12 0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#13 0x081aaa2c in Ferror_message_string (obj=140488123) at print.c:868
#14 0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140488123, data@entry=140488107, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#15 0x0818fb82 in Fsignal (error_symbol=26328, data=140488107) at eval.c:1483
#16 0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#17 0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073748896, arg2=16056) at eval.c:1624
#18 0x0817b0e5 in wrong_type_argument (predicate=-1073748896, value=16056) at data.c:152
#19 0x0822d310 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:170
#20 0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#21 0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#22 0x081aaa2c in Ferror_message_string (obj=140488091) at print.c:868
#23 0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140488091, data@entry=140488075, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#24 0x0818fb82 in Fsignal (error_symbol=26328, data=140488075) at eval.c:1483
#25 0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#26 0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073748400, arg2=16056) at eval.c:1624
#27 0x0817b0e5 in wrong_type_argument (predicate=-1073748400, value=16056) at data.c:152
#28 0x0822d310 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:170
#29 0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#30 0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#31 0x081aaa2c in Ferror_message_string (obj=140488059) at print.c:868
#32 0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140488059, data@entry=140488043, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#33 0x0818fb82 in Fsignal (error_symbol=26328, data=140488043) at eval.c:1483
#34 0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#35 0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073747904, arg2=16056) at eval.c:1624
#36 0x0817b0e5 in wrong_type_argument (predicate=-1073747904, value=16056) at data.c:152
#37 0x0822d310 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:170
#38 0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#39 0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#40 0x081aaa2c in Ferror_message_string (obj=140488027) at print.c:868
#41 0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140488027, data@entry=140488011, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
---Type <return> to continue, or q <return> to quit---
#42 0x0818fb82 in Fsignal (error_symbol=26328, data=140488011) at eval.c:1483
#43 0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#44 0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073747408, arg2=16056) at eval.c:1624
#45 0x0817b0e5 in wrong_type_argument (predicate=-1073747408, value=16056) at data.c:152
#46 0x0822d310 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:170
#47 0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#48 0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#49 0x081aaa2c in Ferror_message_string (obj=140487995) at print.c:868
#50 0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140487995, data@entry=140487979, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#51 0x0818fb82 in Fsignal (error_symbol=26328, data=140487979) at eval.c:1483
#52 0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#53 0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073746912, arg2=16056) at eval.c:1624
#54 0x0817b0e5 in wrong_type_argument (predicate=-1073746912, value=16056) at data.c:152
#55 0x0822d310 in remacs::lists::car (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:170
#56 0x0822d454 in remacs::lists::Fcar (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:185
#57 0x081aa768 in print_error_message (data=<optimized out>, stream=<optimized out>, context=<optimized out>, caller=<optimized out>) at print.c:907
#58 0x081aaa2c in Ferror_message_string (obj=140487963) at print.c:868
#59 0x0818f827 in signal_or_quit (error_symbol=error_symbol@entry=26328, data=140487963, data@entry=140487947, keyboard_quit=keyboard_quit@entry=false) at eval.c:1603
#60 0x0818fb82 in Fsignal (error_symbol=26328, data=140487947) at eval.c:1483
#61 0x081901bc in xsignal (data=<optimized out>, error_symbol=26328) at lisp.h:3817
#62 0x081901bc in xsignal2 (error_symbol=26328, arg1=-1073746416, arg2=16056) at eval.c:1624
#63 0x0817b0e5 in wrong_type_argument (predicate=-1073746416, value=16056) at data.c:152
#64 0x0822d400 in remacs::lists::cdr (object=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:179
#65 0x0822d4b4 in remacs::lists::Fcdr (list=LispObject = {...}) at /home/jeandudey/rust-projects/remacs/rust_src/src/lists.rs:206
#66 0x081414e0 in Fget_buffer_create (buffer_or_name=137842796) at buffer.c:509
#67 0x081459d5 in init_buffer_once () at buffer.c:5234
#68 0x0805d20c in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:1172

OS X compile fails with 'Invalid function: cdr'

When building on MacOS, assuming PR #37 is applied, the build terminates as follows

4480 unused bytes follow Mach-O header
89147 pure bytes used
mv -f remacs bootstrap-emacs
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
  ELC      emacs-lisp/macroexp.elc
Invalid function: eq
make[2]: *** [emacs-lisp/macroexp.elc] Error 255
make[1]: *** [bootstrap-emacs] Error 2
make: *** [src] Error 2

eq appears to be defined in rust_src/src/strings.rs but doesn't make it in to bootstrap-emacs as a symbol

$ strings src/bootstrap-emacs | grep eq
[ not there ]

whereas stringp which is also defined in rust_src/src/strings.rs is a symbol

$ strings src/bootstrap-emacs| grep stringp
stringp
stringp

flycheck-rust keeps warning me

Hi, I'm trying to develop remacs using spacemacs. However this error message keeps flashing out,

Suspicious state from syntax checker rust-cargo: Flycheck checker rust-cargo returned non-zero exit code 101, but its output contained no errors:    Compiling remacs v0.1.0 (file:\                                                        ///home/amos/softwares/remacs/rust_src)                                                                                                                                  
error: Could not compile `remacs`.                                                                                                                                                  
To learn more, run the command again with --verbose.  Try installing a more recent version of rust-cargo, and please open a bug report if the issue persists in the latest release.  Thanks!    

What can I do about it?

Rust?

Sorry, this is not an issue, just a question out of curiosity: does that r before emacs mean you're about to do something in Rust with this repo?

I'll be VERY interested in this. :-)

document build on macOS

What worked for me to build on macOS was the following

  • install and activate rust nightly using rustup
  • install libxml2 headers via xcode-select --install
  • install gnutls via brew install gnutls

then in remacs repo

$ ./autogen.sh
$ ./configure --without-makeinfo
$ make

Could we document it in the README or maybe create a wiki?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.