Recently I started using Emacs as my Scheme (Lisp) editor. I'm thinking what extensions should I use in order to achieve the best performance. Currently I'm using Paredit and it helps a lot. I know that there are numerous Scheme extensions for Emacs: Geiser, Quack to name the two that seem very popular, and EmacsWiki lists many more. Which of these have you guys used and which ones do you find the best? At the moment my biggest problem is lack of parentheses colouring, which makes it vary hard to pair them visually - indentations are not enough when you have a line of code ending with ))))))))
I'm also thinking how could I improve the keyboard layout of Emacs in order to do better in Scheme editing? I've found some good advice on CLiki. I swapped [] with () on the keyboard and that's helpful. I'm also considering swapping Alt and Ctrl keys.
Do you have any other tips and suggestions that make it easier to edit Scheme in Emacs?
I've found rainbow delimiters mode really helpful for highlighting different levels of parentheses.
Among other modes that help me write lisp are hideshow mode for folding of sexps, slime which is primarily for Common Lisp but I use it's indentation capabilities in scheme too, low-contrast color theme called solarized with which my eyes don't fatigue any more and heavily mutated vim mode which permits me to keep my keybindings manageable through editing modes.
I use show-paren-mode, a minor mode, with these in my .emacs:
(show-paren-mode t)
(setq show-paren-delay 0)
(setq show-paren-style 'expression) ; alternatives are 'parenthesis' and 'mixed'
Relevant faces to modify are show-paren-match and show-paren-mismatch.
It only highlights a sexp when point is immediately before or after it, but I like that it's not so in-your-face.
I use autopair to get parenthesis right, show-paren-mode to see the end and beginning of s-expressions and expand-region to mark s-expression (It works on a lot more than that).
I think as you keep playing with paredit you may see less and less need for parenthesis coloring. For example, type ')' within any sexp, and the opening and closing parens will be momentarily highlighted; then point will move to the end of the sexp. Being able to navigate the nested sexp structure easily - for example, C-M-u and C-M-d to navigate up and down one paren level - also takes away some of the need to visually pair parenthesis.
Related
I have some log files that contain the directory paths and file names (and line numbers) for C++, C, Java and C# source code files. I have written a regex to search for these file names and line numbers and open the source code file and position the insertion point at the specified line number (kinda like the next-error function when used with the compile command).
Given a file name that appears in the log file multiple times I want to add highlighting (and selectively remove highlighting) to the source code file display window/buffer.
I can do this with functions like add-text-properties, remove-text-properties and add-face-text-property (where is remove-face-text-property?) if there is no font-lock (keyword color coding). These functions don't work if font-lock is turned on!
How do I do this if the font-lock is turned on? I see that the incremental search feature does it so it is possible to add and remove highlighting with out messing up the font-lock coding.
Thanks
Siegfried
Use overlays instead of text-properties. E.g. to highlight with face bold the text between BEG and END, do something like:
(let ((ol (make-overlay BEG END)))
(overlay-put ol 'face 'bold))
Any highlighting that uses text property face is overruled by font-lock highlighting -- font-lock wants to win. In many cases you can still highlight text, but sooner or later font-lock erases that highlighting when it refontifies the buffer.
This does not apply to highlighting that uses overlays –- font-lock has no effect on overlays. So one answer is to just use overlays. However, if that does not work for your use case (there are some downsides to using overlays) there is still hope.
To prevent the interference of font-lock with other highlighting, the typical Emacs approach is to fool font-lock into thinking that it is font-lock highlighting, even when it does not involve font-lock-keywords.
But this has the effect that such highlighting is turned off when font-lock-mode is turned off. Whether this is a good thing or bad depends on your use case.
In vanilla Emacs you have no choice about this. Either the highlighting is not recognized by font-lock, which overrules it, or it is recognized as “one of its own”, in which case it is turned off when font-lock highlighting is turned off.
If you don't need your special highlighting when font-lock-mode is turned off, then you can just use text property font-lock-face instead of property face.
If you use library highlight.el to implement your highlighting then you can do that just by leaving option hlt-face-prop at its default value of font-lock-face. (Value font-lock-face means that the highlighting is controlled by font-lock. Value face means that font-lock does not recognize the highlighting.)
For the case where the option value is face, if you also use library font-lock+.el then there is no interference by font-lock –- the highlighting is independent of font-lock.
Library font-lock+.el is loaded automatically by highlight.el, if it is in your load-path. It prevents font-locking from removing any highlighting face properties that you apply using the commands defined here.
See Highlight Library for more information.
Is it possible to let Emacs have the cursor be moved off-screen, like most GUI text editors work? This is one of the biggest things that bothers me when I use Emacs over any GUI editor. When I scroll down, the cursor is "pushed forward" by the top of the buffer.
I had previously thought that this was completely impossible, because this is hard-wired into the architecture of Emacs, but then I saw multiple-cursors, which does exactly this for the secondary cursors (assuming you prevent the scrolling functions from acting on the secondary cursors). Is it maybe possible to use multiple-cursors to have the main cursor in some hidden buffer, and the effective cursor being what I actually edit with? Or maybe some other clever trick? Or maybe my Googling has failed me and this is really already possible without any magic?
There is a new package available on GNU ELPA called scroll-restore that attempts to remedy this problem. So far, I have encountered a few bugs, but the package seems to work as-advertised for the most part.
You can test it out by installing it with
M-x package-install RET scroll-restore RET
After the package is installed, you can enable the minor mode with
M-x scroll-restore-mode
Personally, I am binding it to the Scroll Lock key because it seems so incredibly apropos! This is what I am adding to my init file:
(require 'scroll-restore)
(scroll-restore-mode 1)
;; Allow scroll-restore to modify the cursor face
(setq scroll-restore-handle-cursor t)
;; Make the cursor invisible while POINT is off-screen
(setq scroll-restore-cursor-type nil)
;; Jump back to the original cursor position after scrolling
(setq scroll-restore-jump-back t)
;; Toggle scroll-restore-mode with the Scroll Lock key
(global-set-key (kbd "<Scroll_Lock>") 'scroll-restore-mode)
This is a direct copy of an answer posted here: https://emacs.stackexchange.com/a/2273/93
Strictly, speaking you can't move the cursor offscreen, because the underlying C code won't let you do it.
This said, I suspect that your problem can be fixed. Basically, there are 2 aspects:
you don't like the way things look when "the cursor is pushed forward". You could work around that by (temporarily) making the cursor invisible.
you want to "jump back" to the pre-scrolling position as soon as you issue a non-scrolling command. There's probably some package out there that does it for you, but you can do it yourself with some pre-command-hook hacking.
BTW, I'd welcome patches in Emacs which provide some of that functionality. I hate the "auto jump-back" behavior of other editors, but it would be good to record the "pre-scroll" position and then offer a way to jump back to it.
Judging by the context and description of your problem, it looks like you want to browse the buffer while preserving your place of editing. There are at least two tricks for that purpose: marks/registers and splitting in two windows.
https://stackoverflow.com/a/3777598/308668 describes the Emacs' registers that act like Vim's marks. You can check in your place in the file with keying C-x r SPC a (a being a letter of your choice) and you can always come back with C-x r j a.
Some sort of automation is achieved by an external script (goto-last-change.el), described here: https://superuser.com/a/184402/49046.
Alternatively, split the window in two with C-x 2. The newly split windows both show the same location and you can use the other to explore. C-x 0 closes a window when you're done.
I am new to Emacs. I find it is powerful and very convenient IF one can master its set of commands. I also believe anyone can do this with patience, and the eagerness to learn and USE the software. However it will be much nicer for beginners, and seasonal users to have some command helper plugin that do following thing:
When the user start typing any CONTROL or META, COMMAND, or any special keys, a "ajax-like" or "smart search" window appear below or in the minibuffer showing help text like, for example: If I hold "CONTROL", command helper windows shows:
C-p Up one line
C-n Down one line
C-f Forward one character
C-b Backward one character
C-a Beginning of line
C-e End of line
C-x ...
Then if I continue to type "x" while holding "CONTROL", the window will update and show something like:
C-x C-a add-mode-abbrev
C-x C-b list-buffers
C-x C-c save-buffers-kill-emacs
C-x C-d list-directory
C-x C-e eval-last-sexp
C-x C-f find-file
C-x C-h inverse-add-mode-abbrev
C-x TAB indent-rigidly
C-x C-l downcase-region
C-x C-n set-goal-column
C-x C-o delete-blank-lines
I have tried googling it, but it doesn't seem exist yet. So I guess this is more a feature request for EMACS rather then a question. But it is great if somebody can write a plugin/module to do this.
I do not believe this is out there, but I also believe that it is not really needed. It would just clutter the screen, though, maybe for a rookie it might be indeed useful.
For now, you might consider printing a cheatsheet.
Do not lose hope, I learned it without any sort of help, the key is indeed to just use it often.
Also, there is quite a good logic behind it all, so if you read up the structure in a cheatsheet or anywhere else, then it might help you "guess" what is the right key combo sooner than later.
EDIT: I actually myself asked a similar question, at least the same functionality was required. I accepted an answer which apparently mentions that Icicles offers this functionality.
Also, one advise is that after you type the prefix key, e.g. C-c, typing C-h afterwards will show you the possible completions.
This leads me to the following:
I believe we could use code like:
"If last key is a prefix key, run C-h*, switch back to previous buffer and rehit the last prefix key"
*this is a general method, working even for my own poorly designed minor mode
I also don't know an existing package that would do that, but here's a couple of tips.
To get an overview of all available bindings, press C-h b. The displayed buffer looks fairly raw, because it includes all ways used to enter special characters (and they are usually at the top), but you can search it with C-s if you remember at least a part of the command name.
If you know the prefix (e.g. C-x) but don't remember what comes next, you can follow it with C-h instead (type C-x C-h). That will bring up a similar buffer that only contains bindings that start with the same prefix. It's one of the more obscure features, I think.
Speaking of "if I hold Ctrl", though, showing hints when you've just pressed Ctrl and nothing else if currently impossible to implement at the Lisp level. That would require some lower-level changes.
There are too many keybindings in emacs for this to be practically useful.
I agree with the other responses and just wanted to add that I found the built-in tutorial very useful for getting past the basics. You can reach the tutorial with C-h t.
You'll probably end up changing several of the default bindings, but learning them will help you find your way around new modes (assuming that they work in an "emacsy" way).
I come back to this be cause I found a perfect solution and can't live without it: The emacs-helm and which-key
In Emacs I'm editing some source code, and I hit <tab>. Emacs indents the line to n spaces. I'd like to change the amount that indents for that kind of line. How do I figure out what rule emacs applied to indent that line by n spaces?
I want to change n, but I need to figure out which of the many indentation-related variables Emacs just used.
A generic answer is difficult. Some modes will make this more apparent than others, but in the general case (as they are free to implement indentation however they wish) I don't think you'll get away from needing to read some elisp.
Starting with the binding for TAB will work, but might be slightly time-consuming depending on how many layers of indirection are involved.
If you know that the major mode in question implements its own indentation, then one (non-rigorous, but fast) approach that you could try to help track down the functions being called is to use ELP, the built in elisp profiler. elp-instrument-package will instrument for profiling all functions with names matching the prefix string argument you specify. Therefore you might do something like the following in a PHP file (noting that php-mode tells you that it is derived from c-mode)
M-x elp-instrument-package RET php- RET
M-x elp-instrument-package RET c- RET
M-x elp-instrument-package RET indent RET
Now type TAB in your source code, and run M-x elp-results to see which of those instrumented functions were called.
At this point you're on your own -- look for the likely suspects, and see what the code is doing -- but it can be a handy way to filter the search.
Once you've finished, use M-x elp-restore-all to prevent any further profiling.
If you're using a mode based on cc-mode (e.g. c-mode, c++-mode, java-mode, etc.), you can hit C-c C-s and it'll tell you what syntactic category the line is. If you want to change it, hit C-c C-o and you'll be guided through the process. Check out the cc-mode docs on customization for more details: https://www.gnu.org/s/emacs/manual/html_node/ccmode/Customizing-Indentation.html
If you happen to enjoy getting your hands really dirty, there's always the elisp debugger to tell you just what Emacs is up to.
If you hit C-h k TAB you'll find the function that Emacs is running (e.g. indent-for-tab-command) then you can do M-x debug-on-entry RET indent-for-tab-command RET. Now whenever you hit TAB you'll pop up a debugger and can watch the execution step by step.
Depending on your taste for debugging, it's either a maddening or enlightening experience. Either way, don't forget to M-x cancel-debug-on-entry when you're done.
Vim completes words and lines with CTRL-X P and CTRL-L. There's a Emacs plugin called Company mode but this plugin interfere and cause conflicts with lots of things within Emacs (with global linum and yasnippets). I know that I can complete words with CTRL-/ in Emacs. But it is possible to take previously written lines to complete code?
Maybe you're looking for hippie-expand? From that web page (as of this writing, anyway):
HippieExpand looks at the word before
point and tries to expand it in
various ways including expanding from
a fixed list (like expand-abbrev),
expanding from matching text found in
a buffer (like dabbrev-expand) or
expanding in ways defined by your own
functions. Which of these it tries and
in what order is controlled by a
configurable list of functions.
For a comprehensive list of completion options visit the emacs wiki page on completion.
There are a gazillion ways to do completion in Emacs. Some are mode specific, some inline, some configurable and what not. Here is a list of modes that might help you.
Use numberic argument to complete by line, say M-5 M-/ will complete by line, while M-/ alone still complete the normal way.
hippe-expend function has a very useful feature which is :
With a positive numeric argument, jumps directly to the ARG next function in this list. With a negative argument or just C-u, undoes the expansion.
Customize the expansion functions in hippie-expand-try-functions-list and put the function try-expand-line as 5th list element, then you could use M-5 M-/ to complete by line.
This tip is very handy and useful and I highly recommend it.
Also worth noting: if your window manager does not steal Alt-tab, emacs will auto-complete with Alt-tab (I set up my window manager to user the "windows key" instead of alt for this very reason).
If you are using evil, this is the most vim-like solution I use:
(defun my-expand-lines ()
(interactive)
(let ((hippie-expand-try-functions-list
'(try-expand-line-all-buffers)))
(call-interactively 'hippie-expand)))
(define-key evil-insert-state-map (kbd "C-x C-l") 'my-expand-lines)
This way you can use our old friend C-x C-l in insert mode for whole line all buffers completion.
Thanks #ymln for the suggestion of using try-expand-line-all-buffers.