johanvts / emacs-fireplace Goto Github PK

Emacs then complains

Warning (undo): Buffer *fireplace*' undo info was 13108363 bytes long. The undo info was discarded because it exceededundo-outer-limit'.

This is normal if you executed a command that made a huge change
to the buffer. In that case, to prevent similar problems in the
future, set `undo-outer-limit' to a value that is large enough to
cover the maximum size of normal changes you expect a single
command to make, but not so large that it might exceed the
maximum memory allotted to Emacs.

If you did not execute any such command, the situation is
probably due to a bug and you should report it.

You can disable the popping up of this buffer by adding the entry
(undo discard-info) to the user option warning-suppress-types', which is defined in thewarnings' library.

There exist at least 69 packages that contain a file named test-helper.el that also provides the feature test-helper.

This leads to issues for users who have at least two of these packages installed. It is unlikely that such a user would be able to run the tests of all of those packages. If the primary test file of one of those packages does (require 'test-helper), then it is undefined which of the various test-helper.el files gets loaded. Which it is, depends on the order of the load-path.

To avoid this conflicts, you should rename your test-helper.el to <your-package>-test-helper.el and adjust the feature and symbol prefixes accordingly.

Also don't forget to update the require form in your primary test file and/or update references to the library/feature elsewhere. Also, if your primary test file is named something like test.el, then please consider renaming that too (same for any other utility elisp files your repositoroy may contain).

Thanks!

PS: This issue is a bit generic because I had to open 69 issues.

Do you mind if I submit a PR to get this put into MELPA?

The fireplace is still shown. emacs-version:

GNU Emacs 24.4.1 (x86_64-apple-darwin13.4.0, NS apple-appkit-1265.21) of 2014-10-18 on builder10-9.porkrind.org

Thanks ;-)

I really would like show the fireplace in an existing buffer with text/code. So the flames would burn the code!

This is satire, but maybe not entirely satire.

I personally want this fire to be real. Could we spin up a few system threads and use while (true){} in them to start converting that sweet AC into heat?

In some cases fire is showing perfectly:

But if I change the window size a little bit, it starting showing above the status line

Or started showing line breaks:

My fireplace looks like this:

Maybe a bug.

I have emacs 24.5.50.1 compiled with GTK+ 2.24.23.

I can't seem to get the sound working on the fireplace. I'm on spacemacs.
when I try to do M-x fireplace-toggle-sound or C-= I get no sound.

This appears in my message buffer, but it might be a red herring to the sound issue.

Error during redisplay: (fireplace--update-locals-vars #<window 3 on *fireplace*>) signaled (wrong-number-of-arguments (0 . 0) 1)

I'm not sure what the issue is. I did try to explicitly set the variable fireplace-sound-file-path but still have no sound. I tested out the ffplay command in the terminal, and that works.

I initially thought that MELPA wasn't downloading the mp3 so I tried to switch to the github repo.

Hypnotoad is more environmentally friendly than burning fake logs.

I just see a solid red buffer with no actual fire.

Adding smoke makes the top of the fire visible.

GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.16.6) of 2015-09-17 on lgw01-52, modified by Debian

An idea to make it possible to use fireplace to run your cpu at 100% to really generate heat to warm up your cozy room?

I followed the instructions as best I could in the README.md file, and I managed to get things compiled to ~/.emacs/fireplace/fireplace.elc but I'm unable to get this working.

I have a fondness ASCII art and ANSI art, but I think my problem may be that I'm not familiar enough with emacs. I'm using Debian 11 (Linux), and would love to get this running. Thanks!

When the smoke is on, sometimes the particles will be layered on top of the flame. This would be fine, except that the smoke maintains the dark background, effectively cutting a hole into the flame.

Hi,
I'm trying to run fireplace as a startup buffer. In order to do that, I've set the initial-buffer-choice variable to 'fireplace using

(setq inhibit-startup-screen t)
(setq initial-buffer-choice 'fireplace)

in my .emacs file

But when I start Emacs, its shows as an error : Wrong number of arguments: (1 . 1), 0

The same occurs when running it in a .el file
Is it a fireplace error or am I making a mistake ?

Thanks for your help