I'm sat here getting emacs into some sort of usable form, with line numbers, less annoying backup file handling and syntax highlighting. Intent on not repeating the process, I was going to push the entire set of changes into a git repository for easy re-use. But presumably somebody else has already done this and many people just use a 'standard' set of customizations? Is there a place I can simply download a tarball and extract it to my home directory and be done?
I work primarily with Ruby, Python, PHP and C, so don't need anything too magical.
Turning my comment into an answer as requested:
You can use this Emacs Starter Kit.
Related
I've read the TRAMP manual and dozens of forums across the web but I couldn't find an answer to this question. I am trying to set up a link in org-mode that transfers a file from a remote server to my local machine (or vice-versa).
According to the manual I have to write something like
/scp:user#host:filepathonremotemachine
and that's it. No specification of where the file should be moved to, which is weird.
I've tried to do it this way and it simply opened the file (as if I was using ssh); tried other combinations also, without any luck.
There is a specific reason for why I am trying to do this with tramp and not a shell:command link. Any help is very welcome
UPDATE
Apparently TRAMP is less useful than what it promises. That leaves me with the shell:command link option. The problem then revolves around avoiding the openssh window that pops out. The closest solution I found was here and it resumes to setting up an ssh-agent. I am not very familiar with this procedure and I would prefer to use the authinfo.gpg authentication method. Do I have this option? Thanks.
Tramp itself offers just alternative implementations of native Emeacs functions. In this sense, it is dumb, as every library, because it doesn't know what the caller wants.
I'm not an org-mode specialist, but could you please show, which kind of link you have in mind? Without any remoteness, just a link which copies a file locally. Replacing local file names with remote ones will be easy then.
I assume, you need something like an external link, evaluating Lisp code. Like
elisp:(copy-file "/path/src" "/path/target")
The following works (for some definition of "works"):
* link to copy a file
[[shell:scp remote.host.com:/path/to/file /tmp][scp]]
But you must have arranged for passwordless login to the remote host beforehand (e.g. ssh-copy-id your public key to the remote): given that, there is no output in the org buffer, no openssh popup, just the standard question from org-mode asking if you really want to execute the shell command and the file is copied quietly to its destination.
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 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.
Just something that will save changes automatically, while i'm editing say in gedit, or notepad plus plus, or even windows text editor, etc.
I can't seem to find exactly what I'm looking for and svn, bzr, and Git are too complicated. One should be able to start a new project, start writing code, and that's it!
So... I'm going to create a whole new version control system that will be more amazing and simple than all the rest! Unless something already exists? Whether it be online, or a local install, whatevs.
EDIT: Ok, the above paragraph was a bit absurd now that I read it much later. I use Git now, and Git is awesome.
Many text editors will create a backup copy of the prior version when you do a save.
Of course, this is pitiful compared to an actual version control system. You should know that many VCS integrate with editors so commits are very simple quick commands.
The minor time it takes to create a repository is insignificant compared to the time it will save you during the project.
Frankly, this sounds like an argument from ignorance.
I found this nice little Gedit plugin: http://nerdblog.pl/2009/06/01/save-and-commit-to-git-plugin-for-gedit-2-26ave/
From what I can tell from the docs, semantic works by slowly building up an idea of what's in your project by analysing each file (and possibly its neighbours) as you visit them. This is too slow. I'd like to just have it visit all the files in my project. Is there an easy way to do this? Having to visit hundreds of files before I can get decent autocomplete working seems crazy.
I've also got a etags file generated. Can I leverage that somehow?
Relevant info: Emacs on Windows, version 23.2.1
CEDET will automatically parse all files references via #include statements, thus providing pretty good completion. If you are looking to jump around in your files, you can setup CEDET to use GNU Global, CScope, to provide the database needed to move around a project by tag name.
In addition, CEDET will parse your headers and nearby files in idle time, so eventually you will have a complete database of all your local files in about 10 minutes after using the tools the first time. You can speed it up by opening a file, and calling
M-x semantic-debug-idle-work-function
which will go off and do that stuff without waiting.
In the end, I've found that the best solution is to brute-force the parsing of the files manually using a bit of elisp. The best answer I've found to this is here.