Is it possible to have only certain plugins run when first starting emacs?
Let's say I develop in Python and also in Ruby. So I want to have one emacs instance running with Python plugins and another running Ruby plugins.
What I'm imagining is I can call rb-emacs or py-emacs from the command line.
So I think part of my solution lies here
http://stackoverflow.com/questions/2112256/emacs-custom-command-line-argument
And then I can alias the emacs call with the custom switches to one of the above
But then, how can I associate a specific plugin with a specific switch?
Am I on the right track with this? Or should I be doing something else entirely?
Edit:
Since my problem does not seem to be clear, I'll try to reiterate here. I'm not worried about long loading times. I'm worried about potential conflicts between plugins. I've used emacs before but only on a basic scale. Now I'd like to go more in depth with plugins. Though I don't fully understand how the plugins work.
Say I have a plugin (or two or three, I don't know how many it might be) for each language I code in. Won't those conflict with each other? Also, I don't want views / windows that are unneeded for that particular language.
You'll just need a different init file for each of your Emacs instances. Then you can create shell aliases for opening Emacs with those init files.
From the Emacs Wiki:
Start Emacs with a specific init file: emacs -q -l ~/my-init-file.el
Then you'll just set up a shell alias like:
alias rb-emacs=emacs -q -l ~/.rb-emacs-init.el
But why do this with separate Emacs processes? If you're concerned about the startup time, you can use lazy loading of packages or Emacs Server with Emacsclient.
I'm voting for "doing something else entirely", but I'm not 100% sure what the problem you're trying to solve is.
In general you can use mode hooks, eval-after-load, and autoload to ensure that you only load a particular elisp library when it is required.
If your problem is that you're forcibly loading everything and it takes too long, then you need to change your code so that you only load things when necessary. See OptimizingEmacsStartup.
If your problem is that you are setting global values for variables that need to have different values for different projects, then you want to be using buffer-local values for them, either via mode hooks, or using directory local variables.
What is the problem you're trying to solve?
Related
Recently, I found that my emacs starts slowly. Sometimes the startup process takes 30 seconds, sometimes 3 seconds. I guess this is related to network enviroment. However, emacs -q can always start up quickly.
This question is like asking "How long is a piece of string". You have not provided anywhere near enough information. Start with telling us which version of emacs and what platform you running on.
You mention that emacs -q starts quickly, so we can assume the slowness is due to your init file. There are a lot of possibilities and no way for us to tell for sure without analysing your init file. However, there are a few things you can do to help identify possible causes.
#Drew's comment about bisecting your init file is a very useful trick to identify the source of a problem in your init file, particularly when trying to track down an error. It can be useful in identifying major contributors to load time when those contributors can be linked to a specific config option or package load etc. It is less useful when the problem is an overly long inefficient init file with too many packages.
Using a profiler as suggested by #legoscia can help identify areas to focus on, but it will still be necessary to interpret and understand what the profiler is telling you.
My suggestions would be to
Additional Packages. Since the introduction of package.el and the emacs package archives, I've observed a tendency for some users to get a little carried away and install lots of packages just in case. run C-h p and go through the packages you have installed. If you don't use any or you see ones there which you no longer want or use, remove them. Each additional package (depending on how they are loaded - see below) will increase your startup time by some amount as each package will need to be loaded. Loading packages you don't need or want will slow down startup time.
Stuff you don't need or understand. Over time, our init file can grow with stuff and we don't remember why we added it or it can be stuff we have copied from others which we thought we might need and forgot about. Every few months (depending on how often you modify your init - maybe more frequently if you make frequent changes, less if you don't) go through your init file and comment out anything you don't need, don't understand or don't rmember why you added it. Just comment it out, don't delete it. Re-start restart emacs and see if it starts faster and whether features or configuration settings you want/need have gone. If there are, look through the stuff you have commented out and see if anything looks relevant. When you find possible candidates, try to work out what the code is doing (look in the emacs manual, use C-h f and C-h v or C-h m etc to try and work it out. If it relates to a specific package, try M-x customize-package and see if there is built in customization which might give you what you want. Even if you prefer to customize things by hand rather than use emacs' built in customization system, M-x customize-group is a great way to find out what customizations are supported by a package and verify you have variable names correct etc.
Learn emacs autoloads. Emacs has this very useful feature called autoload. There are two main ways of loading packages into emacs. The first is to just do a basic 'require'. This will look for an emacs library with the appropriate name and will read it in and evaluate it (it is like adding the file to your init file, so more lines to evaluate, which means increased load time for your init). The good thing about require is that it just loads the whole file and you know that everything gets evaluated. the bad things is that it can in turn require other files, which can require other files and can result in a much longer init time. To try and address this problem, emacs has the autoload facility. Basically, with autoload, you tell emacs that if it tries to execute a command with the name 'foo', it must first load (require) a specific file which you define in the autoload definition. The advantage here is that emacs doesn't try to load the library until you first try to use it, so there is no increase in load time. The disadvantage is that it can mean there is a delay the first time you use a command and it won't work if other parts of your init use the command (well, it will work, but will have no impact on improving load time).
Switch to use-pckage. There is a very useful package called use-package which can help address all of the issues I've mentioned. It helps compartmentalise your configuraiton, simplifies some common configuration tasks and has support for either setting up a package with autoloads or deferring the loading of a package until emacs is idle. It can help speed up your init time considerably provided you use it correctly. Highly recommend giving it a go. See https://github.com/jwiegley/use-package
I would like to associate sets of buffers/files in emacs with different projects, and switch from one to other. This would involve closing all the buffers associated with the present project and open the files corresponding to the switched-to-project. I tried setting up desktops using bookmarks+ as suggested in https://emacs.stackexchange.com/questions/315/using-desktop-for-basic-project-management but all buffers remain open. I also tried setting up workgroups using workgroups2 (https://github.com/pashinin/workgroups2), but had similar issues. Is there an existing emacs package that could be used for this?
There is an excellent package called Projectile that does exactly what you describe and more.
Alternative suggestion
I recommend that you don't look to emacs to manage buffers, frames, and editor state separately across projects.
Instead, use a desktop manager and create separate desktops for each project. This works well because not only can you have separate emacs instances (that you can be sure are truly separated), but you can also have separate web browsers open to documentation or other project-specific applications that collectively get swapped in and out when you switch between projects.
You say, "I tried setting up desktops using bookmarks+ as suggested in using-desktop-for-basic-project-management but all buffers remain open.".
I guess you mean that switching to a desktop does not kill buffers that existed before the switch. Not by itself, it doesn't. How can it guess which such pre-existing buffers you want killed?
Clearly you do not want to kill all buffers that existed prior to the desktop switch.
To get the behavior it seems you want, you would need to somehow decide, and specify, which such buffers you would like killed. You could, for example, choose to kill all that have a certain mode (perhaps using desktop-buffer-mode-handlers).
With Bookmark+ you can have bookmarks that do more than one thing. In particular, here, you could create a sequence bookmark that chains together (1) a function bookmark that kills all of the buffers you want to kill and (2) a desktop bookmark.
Or you can perhaps make use of desktop-after-read-hook or desktop-buffer-mode-handlers to do some cleanup.
(But it sounds like you have not really thought through exactly what behavior you want with respect to buffers that you do not want to "remain open", so that you can specify it clearly. If you can specify it then you can probably implement it fairly easily, using either desktop hooks or bookmarks or both. Just a guess.)
I currently work on a big Fortran project with emacs, but I have the feeling that my current setup is inadequate to the task.
I use f90-mode with auto-complete (without fortran-specific setup, so I only have completion for opened files), and I really miss function header information on hover (as in elisp code), code-folding, lists of subroutines in the current buffer, lists of included files, info on the origin of subroutines and used variables (C-xC-f to open the source file?), …
How can I best add modern supporting functionality for fortran in my emacs?
Mostly I need tools which help me understanding the projects code.
The project uses its own build tool and copies files from different directories into a build directory before building, actually overwriting some files with different versions of the code, so I need a quite flexible tool which can cope with that.
There's a small Emacs plugin called Fortran-tags. It can find the definition of any variable or procedure under the cursor, so it's similar to Ctags, except that it is able to correctly identify all local and global variables and has some additional features. Also, it is developed with the focus on modern Fortran.
Using fortran-language-server (after installation simply start fortls in the terminal) and lsp-mode in emacs works perfectly.
I now found the f90-interface-browser in elpa.
If you use emacs 24 or later, you can just use
M-x package-list-packages
and then search for f90-interface-browser.
You write (or work on) large, modern fortran code bases. These
make heavy use of function overloading and generic interfaces. Your
brain is too small to remember what all the specialisers are
called. Therefore, your editor should help you.
I was wondering whether there is a way to ask for a specific password when booting Emacs? I think I can ask for a pre-defined password which I can define in my .emacs file but I dont know how? I'm mainly interested to do this in an x- or graphical environment..
btw, I do know that the .emacs file can be seen and etc..but in my case it's not an issue.
I use epg to keep encrypted data in file. Then it simply loaded as normal emacs lisp file, as in my config. EPG will automatically ask for passphrase, and you can analyze return code of load function to determine, was loading successful or not
If I understand correctly, you are in a situation where multiple people share the same account on a computer -- that is, not only will they run the same emacs binary, they also have the same home directory where Emacs searches for the .emacs file.
It seems like you not only want to prevent others from reading the .emacs file, you actually don't want them to be able to run emacs at all.
Unfortunately for you, Emacs can be started with -q or -Q in which case the .emacs file is not evaluated at all. Thus any "protection" that relies on your .emacs file can easily be circumvented.
How about restricting access to the emacs binary instead? Maybe make it only executable for members of a certain Unix group (which of course is pointless if multiple people share the same account), or something along those lines. But note that this will not prevent them from installing their own local copy of Emacs.
After years of experimentation with editors, the fact is I prefer them as minimal as possible. I never use fancy features and the full-feature IDE's become bloated, heavy, and slow. Of course, when I do something that pretty much requires a specific IDE (like Android dev and Eclipse) I have no problems using it. But most of the time, I use gedit for programming.
However, I like many Emacs commands, and I want to use them occasionally. Is there a way to embed Emacs inside of gedit? For instance, I envision pressing alt-q (or whatever combo) and Emacs mode is enabled, and from then on all my key presses in the current tab do Emacs commands. I press alt-q again, and it turns off. This would allow me the best of both worlds. Anything like this exist, or do I need to write this plugin myself?
No.
I've seen discussion of embedding of Emacs in other applications in the past, and the consensus is that even that's not feasible, let alone what you're suggesting.
You'd be better off identifying what gedit does that makes you want to use it instead of Emacs, and extending Emacs to make it do that, too. (There can't be that much --- gedit doesn't do much.) The extra features can just sit there and wait for you, and you'll find it easier to locate and use them if you're comfortable in Emacs-mode already.
(On top of all the other advantages of Emacs, you gain the ability to use the same editor you use in a windowed environment on the terminal --- a huge advantage.)
Or maybe yes . . .
You can use the External Tools plugin of gedit (look for it in Preferences). Add a new command, bind it to the key you want, and use this script:
#!/bin/sh
FILE_NAME=$GEDIT_CURRENT_DOCUMENT_PATH
emacs $FILE_NAME
If you want it to open in the currently-running Emacs, replace emacs with emacsclient, and add the following to your .emacs:
(server-start)
This is kind of backward. Why don't you just use Emacs and stay away from all the extra bells and whistles? It'd probably be easier to coax emacs to emulate gedit than the other way around.
If gedit (a) can be scripted to launch another application with the current file as an argument, and (b) will notice if the file is modified on disk and offer to reload it, then you would have a workaround.