My plantuml-mode in emacs is not working correctly - emacs

I have tried to install and use plantuml-mode in emacs, with no success.
My emacs version: 25.2.2
Operating system: Ubuntu 18.04 x86_64
I have followed the official instructions on
https://github.com/skuro/plantuml-mode
When I load a file it says
"Contacting host: www.plantuml.com:443".
After a few seconds I get the error message
"plantuml-init: Wrong type argument: stringp, nil"
I've looked at
Can't turn on plantuml-mode in Emacs
It didn't help. In a previous attempt I found some other similar help pages, on github and stackoverflow, but I can't find them right now. One was to fix a broken url, and the other was to provide the correct path to the jar file. I fixed both, but none of them fixed my problem.
The above mentioned problem reports are related to the mode's attempts to contact a web server, or to run plantuml. I am not interested in any of them, I prefer to run plantuml myself from the command line. All I want from the mode is syntax highlighing and indentation. It is possible to turn off the other features, to get rid of the errors? Or is there another, simpler mode out there, that doesn't try to contact the web or run executables?
Best regards

The plantuml-mode sends your data to be evaluated at www.plantuml.com by default.
To run it locally, you need to set both the plantuml jar path and the execution mode as described in https://github.com/skuro/plantuml-mode#quick-guide:
(setq plantuml-jar-path "/path/to/your/copy/of/plantuml.jar")
(setq plantuml-default-exec-mode 'jar)

Related

Emacs OSX 10.13 configuration issue

Recently I pass to Emacs org because is really convenient to me to write note there.
So I installed all packages I needed (principally ORG and EVIL) but I didn't understand how to setup everything.
I installed emacs from brew without using cask, I linked it, and I'm sure that I'm using the version that I installed (26.1).
So in my ~/ folder I have a .emacs file in which I set up evil mode, and I have a /.emacs.d/ in which I have a lot of file. The problem is: whatever I wrote in a ~/.emacs.d/init.el seems doesn't effect emacs.
So I said "whatever, I'm going on github and I installed some complete configurations and then I customized them myself". I tried to install these two configurations.
https://github.com/hrs/dotfiles
https://github.com/larstvei/dot-emacs?files=1
But for some reason, after doing exactly what they say on README.org
nothing happens.
In particular the second link, after install and open emacs said I need to have ~/.cask/.cask.el but I don't have it.
Advice?

How can I enable file path autocompletion in the IPython console in PyCharm?

Note: The suboptimal autocompletion (not necessarily of file paths only, but autocompletion in general) is a known issue, and there seems to be no generic quality solution yet. Please see the researched links below.
Path autocompletion in the IPython console in PyCharm does not work well:
c:/U<TAB>
should autocomplete to:
cd c:/Users/
on my machine; instead, the best it manages is:
cd c:/UserWarning
which is plain wrong. IPython in the Anaconda prompt, however, behaves as it should.
My strong assumption (supported by a link, below) is that this is due to PyCharm not using the standard IPython configuration files.
I'm aware of the console starting script in PyCharm:
Settings->Build, Execution, Deployment->Console->Python console
and I've successfully used it to activate a simple magic command I've written.
So here my question: is there a code configuration snippet that could be inserted there, and that could just enable file path autocompletion? Or a pointer to a general description on how IPython configuration files "work", that would enable me to figure it out myself? That is, I imagine, the most doable hack that would solve the problem for the time being.
Alternatively, any experiences with writing your own autocompletion using the following libraries:
IPython.core.completer
IPython.core.completerlib
?
Is that doable? How much work can that be?
Thanks in advance!
My SW-Setup:
I use:
PyCharm Community Edition 2017.2.1
Anaconda 2 (Python 2.7), version 4.3.22 which contains
IPython 5.1.0
on Windows 7 Professional N
Links supporting claims in the question(s) above - just two, due to lack of StackOverflow-"reputation" :(
1) Autocompletion in IPython console in PyCharm not working as it should
JetBrains (creators of PyCharm) knows about this since, at least, two years (please Google it under "PyCharm Console tab completion" or similar, I'm allowed to add just a limited number of links here), and seems to have started working on it, but never finished it.
The discussion states " this is only the initial step to getting full IPython tab completions": https://youtrack.jetbrains.com/issue/PY-9345, but the issue is closed since October 2016.
On StackOverflow there are three questions with similar wording, but not one substantial answer (no, using Ctrl+Space instead of Tab does not solve anything). Again, I can't add more links here.
_2) PyCharm not using ipython_config.py to configure IPython Console:_
https://intellij-support.jetbrains.com/hc/en-us/community/posts/206603035-Which-ipython-config-py-is-used-to-configure-IPython-for-Python-Console-
See the comment by JetBrains at the end of the page.

Emacs, anything and the Everything search tool under Windows 7

I am struggling to get Everything working with anything in Emacs 24.3.1 on Windows 7. Ultimately I want to use anything-locate to browse code directories and subdirectories, as recommended in answers to this question. I did once, briefly, seem to have anything-locate working but I changed something and cannot get it back.
When I enter M-x anything-locate (or, using helm, M-x helm-locate) I get a pattern: prompt but when I enter a search term I get an error message like this:
Locate
'es' is not recognized as an internal or external command,
operable program or batch file.
I assume but do not know for sure that this is related to es.exe which is the command line version of Everything. In my init file I have this:
(add-to-list 'load-path "~/.emacs.d/.emacs.d/elpa/everything")
(setq everything-ffap-integration nil)
(setq everything-cmd "~/.emacs.d/.emacs.d/elpa/everything/es.exe")
(require 'everything)
...and I have edited everything.el so that the
(defcustom everything-cmd "c:/Programme/Everything/es.exe" "Path to es.exe."
line now reads:
(defcustom everything-cmd "~/.emacs.d/.emacs.d/elpa/everything/es.exe" "Path to es.exe."
(EDIT Please note that despite the "~/" convention used above, in reality the paths are fully qualified with c:/blah/blah/blah/.emacs.d/)
I expected this to allow Emacs to find es.exe. And yet it still throws the error message. Any thoughts on how to fix this?
I know this is old, but I found this question when I ran into the same problem with helm, so it might be useful.
The problem was a conflict between how emacs specifies PATH, and how windows does it (similar to juanleon's suggestion).
The solution was to remove all forms that modified the path in emacs, and instead just add es.exe to the windows path.
es.exe is an extra download at the bottom of the voidtools download page, below the old versions, took me a while to find.
It is possible that windows shell (whatever it is) does not know how to expand "~/" (even if emacs does understand it).
A very quick test would be to copy the es.exe in "c:\es.exe" and then repeat the test with the proper change in the configuration of everything-cmd; if it works then just use the whole path.

org mode refile error

Since some time (but I didn't change anything in .emacs), I have some errors with emacs's behaviour :
Remember mode will not kill the temporary buffer on "Ctl-C Ctl-C"
Orgmode will not refile any entry
Both operations complain with error "Not bookmark format"
I restored an old .emacs to make sure that I didn't mess it up but the error persists.
Where can I investigate to find out the problem ?
I have Emacs 24.2.1 since end of august.
The built in orgmode version is 7.8.11 (I see 7.9.2 is out ...)
It's always best to start debugging problems such as this by seeing if the problem still happens when you ignore your init file altogether - try starting emacs with --no-init-file and seeing if you still get the problem. If you don't then it's clearly something in your init file.
You can also get odd behaviour if you've got a local install of Org-mode in addition to the one bundled with Emacs itself - eg if you pull in a newer one through ELPA. If you have a local install through ELPA then you can try uninstalling the Org-mode package and trying again using the built-in Org-mode.
I have something similar to the following in my init file to make it switch to the ELPA-installed Org-mode to avoid such problems (this variant is untested so forgive me if it's not quite right):
(package-initialize) ; load and initialise ELPA-installed packages
(org-reload) ; restart Org-mode with the ELPA package
I filed a bug to the emacs team and they found out that the error comes from a corrupted bookmark file.
I removed my ~/.emacs.d/bookmark file (it was empty) and everything is fine now.

Enabling Flyspell-mode gives an error

I recently had to reimage my windows laptop, and emacs is now giving me a strange error:
"Starting new Ispell process [default]
Enabling flyspell mode gave an error"
I have aspell installed, and it is accessible via emacs. I have attached a picture to show this. I also have (setq-default ispell-program-name "aspell") in my emacs configuration. This same configuration works properly on my other windows machines. What might be the problem here? Image: Aspell in emacs-shell http://img145.imageshack.us/img145/4497/emacsaspell.jpg
You can add the line:
(setq flyspell-issue-welcome-flag nil) ;; fix flyspell problem
to your personal emacs initialization file (~/.emacs.d/init.el, ~/.emacs, ~/.emacs.el, whatever...) and that should bypass the problem for you.
EDIT: This it seems is not the best solution: see the comment below and see Dennis' answer for a better alternative.
EDIT2: As the comment below indicates, deleting the files recommended in this post causes problems when upgrading. If you followed the advice on this post and now regret it (sorry), then to reinstall the deleted files you want to type:
sudo apt-get --reinstall dictionaries-common
You should now be able to upgrade and follow Dennis' solution.
Google sent me here first so I thought I would add another common reason for this error message (at least on Ubuntu systems)
My ubuntu 10.10 fresh install had the following bug:
https://bugs.launchpad.net/ubuntu/+source/dictionaries-common/+bug/619015
which is fixed (as indicated in the link) by deleting
/usr/share/emacs/site-lisp/dictionaries-common/debian-ispell.el
/usr/share/emacs/site-lisp/dictionaries-common/flyspell.el
/usr/share/emacs/site-lisp/dictionaries-common/ispell.el
and all the .el .elc files in
/usr/share/emacs23/site-lisp/dictionaries-common
The reason it seems is the above files are already installed in the emacs23-common,
and the .el and .elc files retain the conflict on live systems (from reading the bug report).
I think there are other problems that can cause this error message, but this solved it for me, and I felt ubuntu is common enough for this to mensioned as another answer.
EDIT: There seems to be a less intrusive solution - see Dennis Sheil's answer
Blessings,
Tom
Writing an answer in order to mark this as accepted:
paprika's comment helped me track the problem -
"Did you check if aspell works outside of Emacs, i.e. something like cat foobar.txt |aspell -a -l en?"
Turns out aspell-en had not been installed. my bad.
I ran into this problem as well when upgrading to emacs24. My aspell was working fine. I tried some of the techniques here with dictinaries-common and settting flyspell-issue-welcome-flag to nil as above but running emacs24 kept hanging on ispell.
I ended up purging my previous emacs23 install (making sure all their .el/.elc files were deleted in the uninstall), making sure there were no emacs processes in the background, and removing my cruft collecting ~/.emacs.d directory (taking care to save code in there I still needed).
I then freshly installed emacs24 (24.1.50.1 as it happens) and ran it and flyspell worked flawlessly.