How to make parenthesis matching work in XEmacs? - match

I tried using all options in the menu setting Options|Display|Paren Highlighting, but nothing works - no parenthesis match is performed. I also tried setting explicitly (paren-mode 'blink-paren t) in my init file, but that did not help either. Any ideas what may be happening and how do I fix it?
Thanks.

I have had paren mode working long enough in my XEmacs that I forget what exactly I did to turn it on, but I did dig these things out which might help.
From my .xemacs/init.el:
(require 'paren)
From my .xemacs/custom.el as part of custom-set-variables:
'(paren-mode (quote sexp) nil (paren))
'(show-paren-mode t)
-John

Related

How can I automatically close brackets in Emacs? [duplicate]

I've just started using emacs, and there's one feature I'd really like, and searching around a bit was fruitless. I hope someone else has done this because I don't want to learn elisp just yet.
void foo()<cursor>
I would like typing an "{" to cause this to happen
void foo(){
<cursor>
}
I would like this to only happen in cc-mode, and only at the end of a line when not in a string/comment/etc
The first thing that came to mind was rebinding "{" to do this always(I could figure out how to do this myself), but it would be hard to make it only happen at the right time.
any hints would be appreciated.
on latest emacs you can use :
electric-pair-mode is an interactive compiled Lisp function.
(electric-pair-mode &optional ARG)
Automatically pair-up parens when inserting an open paren.
this is integrated in Emacs 24.1 (actually CVS)
This will do it:
(defun my-c-mode-insert-lcurly ()
(interactive)
(insert "{")
(let ((pps (syntax-ppss)))
(when (and (eolp) (not (or (nth 3 pps) (nth 4 pps)))) ;; EOL and not in string or comment
(c-indent-line)
(insert "\n\n}")
(c-indent-line)
(forward-line -1)
(c-indent-line))))
(define-key c-mode-base-map "{" 'my-c-mode-insert-lcurly)
turn on electric-pair-mode in emacs 24 or newer version.
(electric-pair-mode 1)
I heartily recommend you to try out the excellent autopair minor mode - it does a lot more than simply inserting braces and makes Emacs a lot more IDE like in that area. I guess combining it with the electric braces setting in cc-mode will give you more or less the behavior you seek.
Try yasnippet (or on the Emacs Wiki page yasnippet). There are many packages for Emacs which support doing this kind of thing, but yasnippet seems to have momentum currently and is very extensible. Check out the videos.
You will need to delve into emacs-lisp to do this exactly as you wish, since YASnippet will do something nice for you but not exactly what you're asking for.
I think the simplest way to do this would be to bind a function to the RET key, in the cc-mode key-map.
The function should check to that the previous character is an { and if so, perform the required RET, RET, TAB, }, Up, TAB to get the cursor where you want and the closing } inserted.
You can make the feature more robust by having it check for a balanced closing } but this would be more complicated, and I'd recommend seeing how it feels without this additional polishing feature.
If you like I can write the function and the key-map binding for you, but since you asked for an idea of how it's done, I'll leave it up to you to ask for more assistance if you need it.
Alternatively, I find that autopair.el does this nicely enough for me, and I do the newlines myself ;)
You might want to keep the option of an empty function body, in which case you would want the closing brace to stay on the same line. If that is the case, then you can try this alternative solution:
Rely on the packages mentioned in the previous replies to automatically add the closing brace.
When you want to add statements to the function body, you press the Return key (while the automatically added closing brace is still under the cursor). The 'Return' key is bound as follows:
;; automatic first line in function
(defun my-c-mode-insert-funline ()
(interactive)
(newline-and-indent)
(when (looking-at "}")
(newline-and-indent)
(forward-line -1)
(c-indent-line)))
(global-set-key (kbd "RET") 'my-c-mode-insert-funline)

How do I tell to flyspell to ignore comment lines on git-commit-mode?

I usually change dictionaries when writing a git commit, however since I have a mapping to to change dictionary and run (flyspell-buffer) right after I see that flyspell goes beyond the commit message to check also comment lines starting with #.
How can I tell "flyspell, please ignore lines starting with # symbol"?
I've read that I can use flyspell-generic-check-word-predicate however my elisp is far from good :(, I came up with this:
(defun flyspell-ignore-comments ()
"Used for 'flyspell-generic-check-word-predicate' to ignore comments."
(not (string-match "^ *#" (thing-at-point 'line t))))
(put 'git-commit-mode 'flyspell-mode-predicate 'flyspell-ignore-comments)
However it doesn't work. What I'm doing wrong?
Ok, thanks to #KyleMeyer for make me doubt about my configuration, the issue was that I had enabled flyspell in a text-mode-hook, and that was interfering with the config for the git-commit-mode. Removing flyspell for loading in the text-mode-hook solved the problem.
Thanks.

How to disable Emacs highlighting whitespace in parenthesis?

In the above screenshot, it can be seen that Emacs highlights the whitespace between parentheses, unless I move my cursor one place to either side.
I have smartparens enabled in my emacs config, but even if I disable them, this problem still persists.
I also don't have whitespace-mode enabled.
Any idea what may be causing this?
The relevant part of my config:
(require 'smartparens-config)
(smartparens-global-mode t)
(show-smartparens-global-mode t)
Thanks.
Unfortunately the solution given by Ignacy Moryc, didn't help me, but this one helped:
(setq sp-highlight-pair-overlay nil)
This looks like show-paren-mode
If you have (show-paren-mode t) anywhere in your config file, you might want to remove it. Or you can change the show-paren-style variable value to parenthesis
(setq show-paren-style 'parenthesis)

Emacs indent-line-function

i try to indent sql file lines in emacs, I think the c-indent-line is pretty good for me, so i write this code to my init file:
(defun my-sql-mode ()
(setq indent-line-function 'c-indent-line)
)
(add-hook 'sql-mode-hook 'my-sql-mode)
But when i use tab to indent the line, it always give me the tips of 'Wrong type argument: stringp, nil'.
Can someone help me?
Indentation in Emacs is generally intelligent, but it's not magic.
c-indent-line is a function designed for use with C and C++ code. It shouldn't be greatly surprising that it might not work in other contexts, and I'm not sure what you were expecting it to do when faced with SQL code?
I'm afraid the answer is simply: Don't do that.
If you tell us what you wanted it to do, however, someone might be able to help.

What does ad-activate do?

In an answer, I noticed:
;; Align with spaces only
(defadvice align-regexp (around align-regexp-with-spaces)
"Never use tabs for alignment."
(let ((indent-tabs-mode nil))
ad-do-it))
(ad-activate 'align-regexp)
This sounds promising, but... what does it do?!
I tried eval-region on the block of code. But for me, all it does is adding the following to the align-regexp docs:
This function is advised.
Around-advice `align-regexp-with-spaces':
Never use tabs for alignment.
I don't seem to be able to actually use align-regexp-with-spaces, if that's what should be the effect... What am I missing?
I used GNU Emacs version 24.0.96.1 (i386-mingw-nt6.1.7601).
While asking this question, I realized that I just didn't get the idea of advising functions.
It became clear to me that:
align-regexp-with-spaces isn't a function nor a variable but only a name (to enable/disable single pieces of advice)
ever since (ad-activate 'align-regexp), align-regexp just does what I 'advised' it to: not to use tabs
So: ad-activate activates the advice, effectively changing the original function's behavior. Great!
I don't get why this is 'better' than defining a function around align-regexp though. But then again I don't know much about Emacs Lisp.
I'm afraid the extra lines of documentation only added to the confusion...