I use ERC for IRC, and would like to colourize some of my messages.
Basically, I want to colourize my input based on a specified major mode.
As an example, if I write /hs 1 + 2, it would colourize, and send the message as if it were in a buffer with Haskell Mode.
I already know how to write slash commands for ERC, I just don't know how to colourize the string based on a mode.
One way to do this -- and I think it is used in other spots, like gnus -- is to make a temporary buffer, set the mode of the buffer, insert the text, and then force it to font-lock. Then, extract the buffer text with properties, and copy that wherever you like.
Offhand I don't know how to force font-locking to happen. You may need to dig into the jit-lock code a bit.
Related
I am using Emacs 23. This comes with OS and I can not change it for some reasons.
Few files I open have long pathnames which are eating all the space and I can not see enabled modes or current line/column. Is there any way to make the mode line multi-line OR some other solution?
Thanks
Perhaps SmartModeLine would help:
Fixed width (if you want): Lets you set a maxium width for the path
name and mode names, and truncates them intelligently
Here is a less complex solution, which may be a little easier for you to modify to suit your own -- it uses a simple function called shorten-directory:
http://amitp.blogspot.com/2011/08/emacs-custom-mode-line.html
I have two buffers open side by side in Emacs. As I delete (or modify) lines in the first file, I would like the second file to receive the same commands / cursor position. Is this possible?
The closest thing I know of to what you've described is the multiple-cursors package, which is pretty cool, but it only implements multiple cursors within a single buffer. So I suppose that you could:
Append one of the buffer contents to the other;
Spawn multiple cursors using the package I mentioned;
Split the windows;
Edit away;
Move the appended buffer contents back to its original location.
With what I suspect would be a considerable amount of hacking, one might be able to extend multiple-cursors to handle multiple buffers, but I think this would be opening up a huge can of worms. What if the two buffers are in different modes, and you enter a key sequence that's bound to different commands that do vastly different things?
I was reading this question and the answers are a convoluted mess (timer function REALLY?)
In any case, I don't care about recreating these buffers, as that is trivial. But these buffers contain information which should never be deleted, and because they don't have associated filenames, they are usually killed without confirmation.
I do have a solution in mind, but I want to see if someone has a more "canonical" one.
jtahlborn provided the most canonical solution, except the "keep-buffers" package is showing its age has some issues:
You had to specify whether all protected buffers are to be buried and erased (erased buffers can be recovered with `undo') when killed, or just buried when killed.
member is reimplemented as find-in-list less efficiently.
Helper functions that didn't really help.
I made the the protected-list an alist that associates regexp to erase-action, and deleted the useless (IMO) code. By default, "scratch" is erased when killed, "Messages" is never erased or killed.
See github
You can try adding a function to the kill-buffer-query-functions variable that checks the current buffer, if it is scratch or Messages then return nil. I've never tried this before but it should prevent them from getting killed.
Edit: Here's an example of using kill-buffer-query-functions that allows you to protect specific buffers: http://www.emacswiki.org/emacs/protbuf-by-name.el
i use the keep-buffers utility.
In addition to what has been said by others --
*scratch* is in no way a "vital" buffer. And by default nothing and no one automatically writes anything to *scratch* or modifies anything there.
(FWIW, I tend to use an ordinary Emacs-Lisp mode file buffer instead of *scratch*. One reason is that I do typically want to save it at some point. (Another reason: I prefer that C-j do what it does in Emacs-Lisp mode. Yes, I could change just that key binding, but instead I keep *scratch* for some kinds of interaction, but typically not for a coding sandbox.)
*Messages* is a different story.
But how are you accidentally deleting *Messages*? In decades of using Emacs I don't think I've ever accidentally killed *Messages*. What's the scenario to produce the problem you are looking for a solution to?
In noweb mode, I would like to make the doc chunks and code chunks easier to distinguish. I'm already using font-lock-mode, but it applies the same face to strings in R and strings in tex, so doesn't distinguish the code and doc chunks very well.
For example, a slightly different background color for the code chunks.
One possibility would be to define a new face for the minor mode of the code chunk, but then that face would also apply when editing a buffer in that mode.
Another possibility would be to create an overlay for the code chunks.
Also, somewhat related, org-mode can be configured to use different background colors for source blocks.
Update: I now use polymode to achive this.
You can use noweb-font-lock-mode from ESS to get syntax highlighting for both code and documentation chunks. I'd recommend you also use noweb-mode from ESS too, because it has some improvements.
One option would be mmm-mode, with which you can define regions that are in a different mode -- it also applies a face to the entire sub-mode region, which you can use to easily distinguish those regions within the parent file.
I personally use this for Ruby within IRB, Javascript and CSS within HTML etc. There's an example for javascript in my emacs config.
The MuMaMo extensions allows different rules for different parts of the file. Getting the nXhtml package will give you the mode and I think you can configure it to do what you want.
When viewing piped output to Less, sometimes I'd like to be able to view it in Emacs in order to get syntax highlighting and use emacs commands for searching, marking, copying, etc.
I see that Less has a v command that can be used to open the currently viewed file in $EDITOR. Unfortunately this doesn't work when viewing piped input.
Also, I don't know how to get Emacs to display stdin as a read-only document.
So, is it possible to set up Less with something like v but that pumps the current buffer into Emacs as a read-only file?
Thanks.
If you scroll down in http://www.emacswiki.org/emacs/GnuClient, you'll come to a section titled "Piping data to an Emacs buffer" which may be relevant. Or you can hack up a solution involving emacsclient and temporary files. (link dead).
I found another variant while looking for a duplicate of the dead link: Piping to an emacs buffer with emacsclient which points at code stored on github.
I've formalized the solution here: github e-sink