How to expand yasnippet in different part of buffer - emacs

Question is simple:
Is there any way how yasnippet can be triggered at one place in the buffer, and executed in another place of the buffer, while returning to original position at the end of expand?
Typical situation is e.g. when coding Verilog design. One needs to define a new signal at the beginning of the module. So ideal would be to trigger the snippet, it goes to the top of the module, executes there, and reverts back to original position.
Thanks

Related

why helm-projectile-recentf set current buffer as default

I'm trying move from ido-mode to helm and projectile and are not used to, something will be overcome, but when I tried helm-projectile-recentf, I wish it can switch to last buffer I visited quickly, but the default buffer is my current buffer, I don't want to switch to my current buffer, I have to move down first. switch buffer is a very frequent operation, I think move down everytime is very annoying!
I have studied helm-projectile-recentf function, it seems it is not easy to customize it to suit my normal requirement.
Could somebody have good suggestion, thanks in advance!

Can I disable window-splitting in a particular frame?

I'm a developer who uses emacs. In emacs I use multiple frames (what most people would call X windows), and the compile function for my builds. I like to have one frame for my compilation buffer, and the others for source. That allows me to navigate to build errors easily and get a nice big view of the source I'm investigating along side a nice big view of my build output. This works fine when I use the 'next-error' function from a source frame.
But when I move my pointer into the compilation frame, and click on an error, it vertically splits that frame to show the relevant source. I want it to show the relevant source in one of my other frames.
Is there a way to "lock" a frame so that it won't be split into windows, and so other frames will be used instead? I'm OK if it splits one of my other frames to display the new source files - just not the compilation frame (because that means I have to unsplit that frame and then switch the buffer of a different frame to display the buffer in question - that's cumbersome).
Alternatively it would be fine if I could use a different mouse button on an error in the compilation buffer to say "visit this file and line in a different frame".
I believe you can achieve your goals by making the window in your "compile frame" dedicated:
Functions for displaying a buffer can be told to not use specific windows by marking these windows as dedicated to their buffers.
Interactively, M-x set-window-dedicated-p should make your window dedicated.
From elisp, something like
(set-window-dedicated-p (selected-window) 1)
should do the same. Replacing 1 with t will make the window strongly dedicated:
As a special case, if flag is t, window becomes strongly dedicated to its buffer. set-window-buffer signals an error when the window it acts upon is strongly dedicated to its buffer and does not already display the buffer it is asked to display. Other functions do not treat t differently from any non-nil value.

What does "buffer's restrictions" mean in save-restriction?

When I search for description of "save-restriction" in Emacs, it has a sentence about "The buffer's restrictions" - I have included the complete description below. What does this term mean? how does save-restriction work and when it should be used considering this?
(save-restriction &rest BODY)
Execute BODY, saving and restoring current buffer's restrictions.
The buffer's restrictions make parts of the beginning and end invisible.
(They are set up with `narrow-to-region' and eliminated with `widen'.)
This special form, `save-restriction', saves the current buffer's restrictions
when it is entered, and restores them when it is exited.
So any `narrow-to-region' within BODY lasts only until the end of the form.
The old restrictions settings are restored
even in case of abnormal exit (throw or error).
The value returned is the value of the last form in BODY.
Unless the purpose of your code is to modify the restriction, current buffer, point or window configuration, then you should use the appropriate save method to remember the state and automatically restore it for you.
save-current-buffer saves the current buffer, so that you can switch to another buffer without having to remember to switch back.
save-excursion saves the current buffer and its current point and mark too, so you can move point without having to remember to restore it.
save-restriction saves the restriction so that you can narrow or widen it without having to remember to restore it.
save-window-excursion saves the complete configuration of all the windows on the frame, except for the value of point in the current buffer.
(Side note: when I last used save-window-excursion there was no window-configuration-p method.)
save-restriction is used by narrow-* functions to save the current buffer , before to hide it, in order to be able to restore it.
'save-restriction' memorizes all 'buffer' data strucuture , in particular point-min, point-max, point-max-marker, etc . For example, before a narrow-function modifies the visibility of a buffer, it memorizes the old configuration, in order to be able to restore it using widen().

Emacs - how to use colors to visually accentuate the function the cursor is in?

Inspired by ia Writer's focus mode, I'm interested in using font + background colors in emacs to accentuate the function the cursor is in and visually cue the rest of the code as the background (I use C++, but it would be nice if this worked regardless of the programming language).
Ideally the font color of code outside the function would be dimmed (this is how focus mode works). A simpler solution probably be to change the background color slightly for the function that the cursor is currently in. How can this be done?
Nothing like this exists AFAIK. If you want it to write it yourself, here is a sketch:
Write a routine that determines the boundaries of the current function. The easiest way to do this is with (bounds-of-thing-at-point 'defun).
Write a routine that, when given the bounds of a region, gets the background face property of the region of the region, darkens it, and applies the new face to the region.
Override font-lock-fontify-region-function (see here) with a routine that calls the original value of this variable, differences the region given with the region of the current defun (using #1), and then applies routine #2 to the remaining region.
I would prefer overriding font lock to, say, using jit-lock-register because you need to control the order of fontification.
HTH!
Which-function mode is used to highlight the current function. Try it to see if it helps you, and see if this post helps you:
Emacs Setting which-function-mode

Figure out what buffers have been opened by a function in elisp?

I'm trying to write a plugin that calls a function (icalendar-import-file) which has the nasty side effect of opening between 1 and 3 buffers every time it is called, and sometimes I want to call it a whole bunch of times.
I can't even find a function that will list buffers without popping up a new buffer, which is a little frustrating.
As far as I can tell that defun (ical...) doesn't return anything useful, so the two obvious solutions to me are to either: (1) set a variable to a list of buffers before I run the function, and then sweep through the buffers that exist after the function exits and delete the new ones, (something like save-excursion, but for buffers) or (2) somehow suppress the creation. It looks like ical... is pretty heavily dependent on this, though, so I'm not sure that that's feasible.
Are you looking for the function :
buffer-list is a built-in function in
`C source code'.
(buffer-list &optional FRAME)
Return a list of all existing live
buffers. If the optional arg FRAME is
a frame, we return the buffer list in
the proper order for that frame: the
buffers in FRAME's `buffer-list' frame
parameter come first, followed by the
rest of the buffers.
If you know which function is creating the unwanted buffers, and understand what effect removing them will have, you could always advise them (using after advice) to remove the unwanted buffer right at the source of the problem. I think this is safer than simply removing any new buffer once a function has finished.