kwrooijen / cargo.el Goto Github PK

when emacs is split into 2 or 3 windows, hitting c-c c-c c-r to run the code will make cargo buffer displayed in one of the split windows.
is there a way to open cargo buffer only inside current window like helm ( helm-split-window-in-side-p )? not automatically taking one of the other windows

cargo fmt doesn't seem to support --manifest-path anymore. See rust-lang/rustfmt#2817

As the pic says, in the latest Cargo, there is no upgrade subcommand. So maybe we need to remove the cargo-upgrade action to keep up with the Cargo, and make cargo.el more compact.

$ cargo --version
cargo 1.42.0 (86334295e 2020-01-31)

I get: json-read: JSON readtable error: 47

GNU Emacs 26.1
rustc 1.36.0-nightly (7c71bc320 2019-04-30)

I use direnv (with direnv-mode). cargo and rustc are not available on my system without it.

According to this rustfmt package in future will be obsolete. And current mainstream is rustfmt-nightly crate, which in future become part of standrard rust dictirbituion.

But at now it is impossible to use rustfmt-nightly if you want to use stable rustc/cargo at the same time. To run rustfmt nightly and use as default stable branch of rustc/cargo you need such commands: cargo +nightly fmt or rustup run nightly cargo fmt.

I can not see how to configure cargo.el to use one of theese commands in M-x cargo-process-fmt. As work around I can only create custom shell script cargo, set path to it via cargo-process--custom-path-to-bin, and in this script forward comamnds to suitable versions of cargo, not neat.

May be possible to create configuration like cargo-process--custom-cargo-fmt-command?

Using cargo v. 0.19.0, output in the compilation buffer is mangled by unhandled ansi escape codes. For example when running cargo build via cargo.el, the output might look like this:

-*- mode: cargo-process; default-directory: "~/dev/lang-misc/rust/many-channels/" -*-
Cargo-Process started at Sun Sep 10 16:10:36

cargo build 
�[m�[m�[32m�[1m   Compiling�[m c_vec v1.2.1
�[m�[m�[32m�[1m   Compiling�[m pkg-config v0.3.9
�[m�[m�[32m�[1m   Compiling�[m gio v0.2.0
�[m�[m�[32m�[1m   Compiling�[m bitflags v0.9.1
�[m�[m�[32m�[1m   Compiling�[m libc v0.2.30
�[m�[m�[32m�[1m   Compiling�[m gdk-pixbuf v0.2.0
�[m�[m�[32m�[1m   Compiling�[m gdk v0.6.0
�[m�[m�[32m�[1m   Compiling�[m gtk v0.2.0
�[m�[m�[32m�[1m   Compiling�[m cairo-rs v0.2.0
�[m�[m�[32m�[1m   Compiling�[m lazy_static v0.2.8
�[m�[m�[32m�[1m   Compiling�[m gdk-sys v0.4.0
�[m�[m�[32m�[1m   Compiling�[m cairo-sys-rs v0.4.0
�[m�[m�[32m�[1m   Compiling�[m gio-sys v0.4.0
�[m�[m�[32m�[1m   Compiling�[m gtk-sys v0.4.0
�[m�[m�[32m�[1m   Compiling�[m gdk-pixbuf-sys v0.4.0
�[m�[m�[32m�[1m   Compiling�[m glib-sys v0.4.0
�[m�[m�[32m�[1m   Compiling�[m atk-sys v0.4.0
�[m�[m�[32m�[1m   Compiling�[m gobject-sys v0.4.0
�[m�[m�[32m�[1m   Compiling�[m pango-sys v0.4.0
�[m�[m�[32m�[1m   Compiling�[m glib v0.3.1

Running cargo commands while passing the --color never flag seems to ameliorate the problem, but there is no easy way to have cargo.el use that flag by default as far as I can tell.

Arguably this is a problem with cargo itself, but you can work around it easily in the shell.

Setup

1. create a cargo workspace
2. add a subworkspace
3. in the subworkspace, create a .cargo/config with, eg
   [build] target = "thumbv6-none-eabi"
4. try to build the subworkspace in emacs.

Results

You'll get a bunch of linker errors. I realize the setup is pretty vague, but you can find a sample project that has this problem here

Investigation

The reason this happens is because the various cargo commands, spawned from cargo-process--start specify default-directory as (or (cargo-process--workspace-root) default-directory), where the latter default-directory points to the sub-workspace root.

If the let binding on default-directory is removed from the subsequent compilation-start call (thus pointing default-directory at the result of cargo-process--project-root), the sub-workspaces will compile correctly.

I assume there's a reason for overriding default-directory before calling compilation-start, but I don't know what it is, as everything appears to work correctly without it, with the added bonus that the problem described above goes away.

Use case

Some times when I run tests I need backtrace (RUST_BACKTRACE=1),
but need it only in 10% cases, in 90% cases panic! message enough by itself,
and backtrace is overflow compilation buffer, make it harder to read panic! message.

Yes, I know about cargo-process--enable-rust-backtrace, but I want to change
it online without much efforts, plus see bellow.

Also time to time I need debug!, trace! output during test run,
I can do it via RUST_LOG=module=debug, but again I don't need it permanently.

So what about adding interactive commands like cargo-add-env and cargo-clear-env?

Problem:

Currently, cargo.el hardcodes commands that it can execute. It's not possible to execute a command that cargo.el is unaware of.

Solution:

cargo provides cargo --list command which lists all available commands. It can be used to select a command using completing-read.

This approach is used in mix.el - https://github.com/ayrat555/mix.el

See sample project: https://github.com/nebgnahz/cargo.el-workspace

For a project with workspace, Cargo returns issue relative to the workspace root
directory. cargo.el instead find the directory with Cargo.toml, which can be
different. When these two project root directory differ, Emacs compilation mode
fails to find the correct file path. To a user, Emacs is unable to jump to the
error location and a window prompt is open.

In the linked sample project, the file in add-one/src/lib.rs has a typo x1. When one
does a cargo build, we see the following compilation log:

-*- mode: cargo-process; default-directory: "~/repos/cargo.el-workspace/add-one/" -*-
Cargo-Process started at Mon Dec 25 15:50:13

cargo build
   Compiling add-one v0.1.0 (file:///Users/benzh/repos/cargo.el-workspace/add-one)
error[E0425]: cannot find value `x1` in this scope
 --> add-one/src/lib.rs:2:5
  |
2 |     x1 + 1
  |     ^^ did you mean `x`?

error: aborting due to previous error

error: Could not compile `add-one`.

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

Cargo-Process exited abnormally with code 101 at Mon Dec 25 15:50:15

And Emacs wants to open a non-existant file
~/repos/cargo.el-workspace/add-one/add-one/src/lib.rs. cargo.el finds file
relative to ~/repos/cargo.el-workspace/add-one/ while Cargo
~/repos/cargo.el-workspace/.

Note: this wasn't an issue for old Cargo/cargo.el. I did a package update today and start experiencing this issue.

Edit:

$  cargo --version
cargo 0.25.0-nightly (e08f31018 2017-12-24)

// emacs package-list-packages
     Status: Installed in ‘cargo-20171218.855/’ (unsigned). Delete
    Version: 20171218.855
    Summary: Emacs Minor Mode for Cargo, Rust's Package Manager.
   Requires: emacs-24.3, rust-mode-0.2.0
   Keywords: tools 
Other versions: 20171218.855 (melpa).

When I use cargo-process-test only the first time the buffer is named "Cargo Test" the following times the buffer is "Cargo Process"

Same happens for other commands, only the first time the buffer has the correct name

I suppose that's because the first time a buffer named "Cargo Process" is created and then renamed "Cargo Test", the following time "Cargo Process" gets created and then the rename fails because there's another buffer with the same name

Out of curiosity, why do you do that? Why not just use get-buffer-create?

The error is
JSON readtable error: 79

All packages up to date.
Emacs 26.2
FreeBSD 13

As the title says. You would expect it to let you feed it the name of the bin you are trying to run, but it doesnt. In cargo-process.el, if you change (interactive) to (interactive "sName (leave empty for none): "), it behaves as I would expect it to.

Thanks, and thanks for this free peice of software that makes things more convenient!

If create dummy crate with cargo new foo,
and create subdirectory foo/tests

cargo new foo && cd foo && mkdir tests && touch tests/dummy.rs

with such dummy context:
$ cat tests/dummy.rs

#[test]
fn test_dummy() {
   println!("do nothing");
}

then M-x cargo-process-current-test can not run test (I placed cursor at println!),
because of it run cargo test ::test_dummy, while it should not use ::,
so it runs 0 tests.
Plus M-x cargo-process-current-file-tests run cargo test nil command,
which one obviously not run any tests.

Terminal users need another way to conveniently access clippy. Thanks

I'm working on a rust project that doesn't really build by default

Is there a way to override the defvars such as cargo-process--command-build?
If that's not possible, we could introduce overridable default options for the cargo command-line?

If I click on the file location of an error, it should take me to the location of the error, but instead it opens up a file search dialog. This is because the "default directory" is wrong.

My project has a workspace which is probably triggering the problem. I've checked the code and it seems to be looking up the file tree until it finds a Cargo.toml, and then it uses this directory as the "default directory". Unfortunately, because my subdirectory (containing the workspace member) also has a Cargo.toml, it is stopping too early and using the workspace member directory as the "default directory" when it should be using the parent (top level, whole workspace) directory as the "default directory".

This might be the same as errors #31 and #56, but those have been closed and I am getting this error.

For example, upon running cargo-process-run, I get the results in the buffer fine, but it takes some kind of input (movement or other command) to font lock. Is this a known issue?

Currently errors without explain identifiers are highlighted. Those errors with explain identifiers aren't highlighted (i.e. the word "error" isn't highlighted so as to stand out), although the identifier itself does have a face.

Would it be possible to highlight the word "error" for those cases which include an explain identifier? I style them red so that they stand out to me when skimming the log, and it looks weird that these aren't.

One way to accomplish this might be to use negative lookaheads, which elisp doesn't have. The simpler way might be to simply match on any error at the beginning of a line, which I think should be safe. I don't think the word "error" would appear at the beginning of a line unless it were an error. Here's the result on my end:

I did this by simply changing the pattern to:

"^error\\:?"

I'm not sure if warnings also ever contain explain identifiers, if so it may be useful to do the same with its pattern.

Just as in the pictures below.

Is there any way to remove them? they are really annoying when there are lot of tests.

Thanks for the useful library! Sometimes, I have code that really needs the optimizations from --release to be efficient. How can I pass that flag along?

I didn't see anything obvious in the README or in a quick perusal of the source.

Hi folks,

I have a funny issue: the buffer being used doesn't seem to be re-used and 'jumps' around. Let's say I start like so and want to 'cargo run':

resulting in:

run again:

run again:

etc:

Can't say I've ever seen this behaviour from other in-emacs builders. Is this expected?

It'd be cool if this (from the compile output):

help: run `rustc --explain E0210` to see a detailed explanation

Could include the output of running rustc --explain E0210 inline.

it be nice if there was a variable I could set to t to say to cargo mode to run cargo format when I save a buffer. I tried calling the cargo-process-fmt from my config with a before save hook but it dosn't seam to work

Using a non-existing directory gets blocked by the readline with [No match].

1. M-x cargo-process-init
2. Enter /tmp/new-prj and hit enter
3. Emacs says [No match]

Is it currently possible to set up a shortcut to run cargo run --example <name>? (I'm new to emacs--apologies if there's an obvious place to set this up that I'm just not seeing.)

When I try to create a cargo package with new or init it asks me for the project name then asks if i want to create a bin project to which i answer yes. I then get a Json readtable error: 101

it doesn't matter if i enter y or no for the bin project the error is the same. Did I configure something incorrectly?

Here is the config file i am using:
https://github.com/admintome/emacs-rust/blob/master/emacs-el

compilation-mode has the nice feature of saving buffers before starting to compile (by default asking for it, but that can be customized off in compilation-ask-about-save). This helps streamline the fixup-rebuild flow a lot.

The current value of cargo-process-test-mod-regexp is too strict so it does not match valid identifiers for module names.

Current:

(defconst cargo-process-test-mod-regexp "^[[:space:]]*mod[[:space:]]*\\w+[[:space:]]*{")

What works:

(defconst cargo-process-test-mod-regexp "^[[:space:]]*mod[[:space:]]*[_[:alpha:]][_[:alnum:]]*[[:space:]]*{")

I'll open a PR.

(cargo-process--project-root) returns the directory of Cargo.toml, but cargo is not run from that directory, which messes up cargo clippy for example:

src> cargo clippy
thread 'main' panicked at 'could not find matching package', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/option.rs:715
note: Run with `RUST_BACKTRACE=1` for a backtrace.

It seems like setting

(setq cargo-process--enable-rust-backtrace t)

by default may be a nice thing to do.
Anyways it would be nice have this variable mentioned in the readme. I know it can be discovered in customize interface, but still. Thanks!

When I'm using cargo-process-new to create a new bin or lib, how can I make the cargo-process-new open the main.rs/lib.rs file automatically after creating the bin/lib?

I use emacs24, I cannot use any of the cargo commands such as build/run at all, I get the following error:

cargo-process--workspace-root: Symbol's function definition is void: alist-get

same configuration when copied to emacs25-nox seems to work :(, I would like to use emacs24 if supported? Any help?

The following is my rust/cargo related configuration:

* rust coding
** rust major mode
#+BEGIN_SRC emacs-lisp
      ;; install major mode
      (use-package rust-mode
         :ensure t
         )

      ;;install cargo minor mode
      ;; C-c C-c C-b to run cargo build
      ;; C-c C-c C-r to run cargo run
      ;; C-c C-c C-t to run cargo test
      (use-package cargo
        :ensure t
        :config 
        ;; change emacs PATH to include cargo/bin
        (setenv "PATH" (concat (getenv "PATH") ":~/.cargo/bin"))
        (setq exec-path (append exec-path '("~/.cargo/bin")))
        )

    ;;;
    (add-hook 'rust-mode-hook 'cargo-minor-mode)

    (add-hook 'rust-mode-hook
              (lambda ()
                (local-set-key (kbd "C-c <tab>") #'rust-format-buffer)))

    ;;install code completion
    ;; required step - clone rust src with:   
    ;;     git clone https://github.com/rust-lang/rust.git
    ;; required step - install racer with: (oh this step requires rust - nightly)
    ;;     cargo install racer 
    (use-package racer
      :ensure t
      :init
      ;; set rustup binaries PATH
      (setq racer-cmd "~/.cargo/bin/racer")
      ;; Rust source OWN! rust code PATH
      (setq racer-rust-src-path "~/Apps/rust/src/") 
      (add-hook 'rust-mode-hook #'racer-mode)
      (add-hook 'racer-mode-hook #'eldoc-mode)
      (add-hook 'racer-mode-hook #'company-mode)
      )


     ;;error check
     (use-package flycheck-rust
       :ensure t
       :config
       (setq flycheck-rust-cargo-executable "~/.cargo/bin/cargo")
       (add-hook 'flycheck-mode-hook #'flycheck-rust-setup)
       )

      ;;activate yasnippets for rust
      (add-hook 'rust-mode-hook
                '(lambda ()
                   (yas-minor-mode-on)))


#+END_SRC

How to enable cargo-minor-mode for Cargo.toml via use-package?
This snippet just overrides default conf-toml-mode and disable syntax highlightning.
=/

(use-package cargo
  :magic ("Cargo.toml" . cargo-minor-mode)
  :hook (rust-mode . cargo-minor-mode))

The RUST_BACKTRACE env-var should basically always be set while developing.

It would be helpful, when cargo-init opens the main.rs or lib.rs, because this is often the next step after init.

Symptom

I've been debugging an issue I've had, where compiling/testing/... Rust code from emacs would produce an error similar to this one:

-*- mode: cargo-process; default-directory: "~/Workspaces/Rust Workspace/<projectname>/" -*-
Cargo-Process started at Tue Sep 11 14:13:53

/Users/<redacted>/.cargo/bin/cargo build --manifest-path /Users/<redacted>/Workspaces/Rust Workspace/<projectname>/Cargo.toml 
error: Invalid arguments.

Usage:
    cargo build [options]

Cargo-Process exited abnormally with code 1 at Tue Sep 11 14:13:53

Cause of individual symptom

As far as I know the cause of the problem is as follows: the function cargo-process--project-root in cargo-process.el does not properly escape the path to the manifest. file-truename does not escape whitespaces. Since my projects are in a directory named "Rust Workspace", the paths to the TOML files are affected.

Workaround

Wrapping the call to file-truename in a call to shell-quote-argument seems to resolve the issue.

However:

• I don't know enough about emacs Lisp to know whether this is safe and reasonable;
• I don't know enough about the structure of cargo.el to know whether this is the right place to apply this change; and
• I couldn't properly test this deployed from my local cargo-process.el-file, since my system uses a compiled version, and I don't know how to get emacs to do that with my changed file.

I therefore refrained from attempting a proper pull request.

Additional info

• I use the this emacs package via the Rust layer of Spacemacs, though that shouldn't matter in this case.
• I encountered this problem on a system running macOS, though unescaped spaces in paths are problematic on all common platforms.

I use tests template that provide cargo new:

#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {}
}

if I put cursor to it_wors and command emacs: M-x cargo-process-current-test
it run cargo test lib::it_works, and running 0 tests as result.

It should run cargo test tests::it_works to really run it_works.

First of all, I'm not sure if this is a problem with cargo.el, but it is my best guess. I will try to explain my situation as best as possible.

I'm working on an OpenGL project that I have been able to execute from emacs using cargo-process-run up until now. The project is in a workspace. After updating spacemacs to develop and all packages, I suddenly started getting the following error when running cargo-process-run:

thread 'main' panicked at 'Failed to initialize any backend!
    Wayland status: NoCompositorListening
    X11 status: XOpenDisplayFailed

When I run cargo run -p xxx from the command line, the application runs as it has before.

Do you know of anything that has changed recently in emacs, rust-mode or one of its dependencies that might have changed the environment in which the process is ran?

Hi. I want to run my tests as:

cargo test -- --test-threads=1   --nocapture 

Is it possible now?

The binding C-c C-c C-h was recently added (4fdf141) for cargo-process-doc-open. Unfortunately, this prevents use of C-c C-c C-h to access help for the C-c C-c prefix. See the Emacs Key Binding Conventions:

Don’t bind C-h following any prefix character (including C-c). If you don’t bind C-h, it is automatically available as a help character for listing the subcommands of the prefix character.

I suggest switching to a different key binding for cargo-process-doc-open. A good option is C-c C-c C-v, which reminds me of "view".

By the way, thanks for creating this minor mode! I use it constantly, and it really speeds up working with Rust.

Looks like #76 breaks test running thing for me.

I have

My code looks like this:

mod tests {
    #[test]
    fn test_double_map_err() {
        do_parse(
            "double_map_err",
            r#"
mod swig_foreign_types_map {}
mod swig_foreign_types_map {}
"#,
            64,
            HashMap::new(),
        )
        .unwrap_err();
    }

    #[test]
   fn another_test() {
   }
}

And after #76 cargo.el tries to run swig_foreign_types_map::another_test instead of tests::another_test

I revert
git diff 8a79f4e..5462994
(cd ~/.emacs.d/elpa/cargo-20190101.2043 && patch -p1 -R)

and all starts work again as expected

cc @ralexstokes @kwrooijen

There is problem in interpreting results of cargo test at first glance,
for example rust-lang/cargo#4324 .

It would be nice if cargo.el parse results of cargo test,
I mean lines like test result: ok. 16 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out and at the end provide total amount of failed, ignored and filtered out tests.

I have never run cargo new inside a buffer with cargo-minor-mode.

Found the following in the console:

Warning (bytecomp): defcustom for ‘cargo-process--command-flags’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-bench’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-build’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-clean’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-doc’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-doc-open’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-new’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-init’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-run’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-run-bin’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-run-example’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-search’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-test’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-current-test’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-current-file-tests’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-update’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-fmt’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-outdated’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-check’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-clippy’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-add’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-rm’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-upgrade’ fails to specify type [2 times]
Warning (bytecomp): defcustom for ‘cargo-process--command-audit’ fails to specify type [2 times]

Should be fairly easy to fix, I would assume?

I recently upgraded to Emacs 27 and this broke cargo-minor-mode for me.

Whenever I run cargo-process-check my mode line is flooded with the same error:

compilation-parse-errors: Wrong type argument: stringp, nil

Here's the backtrace:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("\\`\\([^^]\\|\\^\\( \\*\\|\\[\\)\\)" nil)
  compilation-parse-errors(224 #<marker at 276 in *Cargo Check*>)
  compilation--parse-region(224 #<marker at 276 in *Cargo Check*>)
  compilation--ensure-parse(276)
  compilation-filter(#<process cargo-process> "    Blocking waiting for file lock on package cach...")

Specific version: GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.8) of 2019-12-05

In https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html, it says that "Sequences consisting of C-c followed by a control character or a digit are reserved for major modes. "

I don't know how important these conventions are to follow, but personally, I'd like it if I could set the prefix that this minor mode uses. That would satisfy the conventions and also make it more flexible.

cargo derives a minor mode from compilation-mode. The latter is defined in the compile package, thus cargo should (require 'compile) before using that mode. Otherwise you might get an error if you load cargo before loading compile (see below), which happens in my case.

Debugger entered--Lisp error: (void-variable compilation-mode-map)
  byte-code("\301 �\244\207" [compilation-mode-map make-sparse-keymap] 2)
  (defvar cargo-process-mode-map (byte-code "\301 �\244\207" [compilation-mode-map make-sparse-keymap] 2) ("/home/fifr/.emacs.d/elpa/cargo-20160109.427/cargo-process.elc" . 514))
  #<subr require>(cargo-process nil nil)
  ad-Advice-require(#<subr require> cargo-process)
  apply(ad-Advice-require #<subr require> cargo-process)
  require(cargo-process)
  byte-code("\300\301!\210\302\303\304\305\306\307\310\311&�\207" [require cargo-process custom-declare-group cargo nil "Cargo group." :prefix "cargo-" :group tools] 8)
  #<subr require>(cargo nil noerror)
  ad-Advice-require(#<subr require> cargo nil noerror)
  apply(ad-Advice-require #<subr require> (cargo nil noerror))
  require(cargo nil noerror)
  (not (require (quote cargo) nil (quote noerror)))
  (if (not (require (quote cargo) nil (quote noerror))) (ignore (message (format "Could not load %s" (quote cargo)))) (condition-case err (progn (add-hook (quote cargo-process-mode-hook) (function (lambda nil (toggle-truncate-lines -1)))) (define-key cargo-minor-mode-map [f5] (function (lambda nil (interactive) (save-some-buffers) (cargo-process-repeat))))) ((debug error) (ignore (display-warning (quote use-package) (format "%s %s: %s" "cargo" ":config" (error-message-string err)) :error)))) t)
  (progn (progn (require (quote package)) (use-package-ensure-elpa (quote cargo))) (if (not (require (quote cargo) nil (quote noerror))) (ignore (message (format "Could not load %s" (quote cargo)))) (condition-case err (progn (add-hook (quote cargo-process-mode-hook) (function (lambda nil (toggle-truncate-lines -1)))) (define-key cargo-minor-mode-map [f5] (function (lambda nil (interactive) (save-some-buffers) (cargo-process-repeat))))) ((debug error) (ignore (display-warning (quote use-package) (format "%s %s: %s" "cargo" ":config" (error-message-string err)) :error)))) t))
  eval-buffer(#<buffer  *load*> nil "/home/fifr/.emacs" nil t)  ; Reading at buffer position 52395
...