For vim there is a filesystem explorer called NERDtree: https://github.com/scrooloose/nerdtree
Surely an alternative or superior package exists for Emacs?
I prefer dirtree (screenshot below) by Ye Wenbin. It feels pretty close to NERDTree / the TextMate drawer.
It took me a few minutes of trial and error to figure out the dependencies, so take a look at the install instructions (and a few minor edits to the source) I've got in this repo.
You can try NeoTree .
https://github.com/jaypei/emacs-neotree
Screenshot:
Have you looked at Speedbar ?
The Sunrise Commander seems to be a well written package, and it has a tree extension. For a screenshot of the tree extension in action, follow this link.
Who needs any tree, when you have the mighty ido-mode . If you can train your mind to find the files, rather than just your eyes whilst visually finding it, you will win. NO need to tell me how biology works, i don't care :-) you get the point.
Personally, I prefer the ECB's tree mode.
http://ecb.sourceforge.net/
You should also check out the CEDET stuff.
http://cedet.sourceforge.net/
They contain a lot of other useful stuff that you can use for similar development needs.
I use a little of emacs-nav and a little of dired to navigate my projects' file trees. For file management tasks, I mostly use bash (often from within emacs).
(Shameless reanswer from A good project tree browser for Emacs? - Stack Overflow)
I just now did a word search for "explore" in package-list-packages, and discovered project-explorer. Seems to fit exactly what I want today (I don't code hardly, but getting a grip on the structure of my Jekyll site).
Keys include TAB for folding and unfolding directories. Open files with RET or f, but with prefix, it will prompt nicely for which window, and even from there allow you to decide to use window or open up a new one to any side (I didn't find the prompt string in the package code, so it seems to leverage built in Emacs functionality nicely; indeed it looks like dired even).
It's available on Melpa and Marmalade, and packaged description points to sabof_project-explorer ยท GitHub.
I include the site's image for convenience:
I don't use projectile or helm, but it has some integration.
Try out lusty-explorer. It's a well done plugin.
Get it here
Related
In Linux (probably also in Windows/OSX) if we open a file to write and while writing to it we rename it, the raku process goes smooth and keeps writing to the file as it should.
But how can we find the new name (path) of the file while the renaming happens?
IO::Notification is NOT the way to go because it gives no other information but only the general description:
FileRenamed or FileChanged
Is there a way to do it?
Short answer: No, not as far as I know.
Some technical background here: Rakudo on MoarVM (which is the only backend that supports IO::Notification afaik) depends on libuv for this functionality. If libuv doesn't support it, there only a very small chance that Rakudo will.
I have no idea if libuv supports that functionality. If it does, I suggest you make an issue in MoarVM to draw attention to this. Or even better, write a Pull Request to implement that functionality.
Is it possible to open files in Emacs in way that Sublime Text 2 does (Cmd+P or Ctrl+P)?
I miss this feature so much.
Have you tried Helm? It provides a unified history and buffer selector, which looks similar to what you want. You could bind the helm-mini command to a convenient key like F5.
You can check out Projectile. It was basically created to provide something similar to C-p, but has a lot of extra project level features as well. Projectile also has a Helm plugin to display project files and buffers with Helm.
I'm trying to make a GTK+ interface in glade that has you select where to save a file. I tried using the GtkFileChooserButton widget, but when I run it, I get the warning
Gtk-WARNING **: gtk_file_chooser_button_set_property: Choosers of type `GtkFileChooserButton' do not support `GTK_FILE_CHOOSER_ACTION_SAVE'.
and the dialog wants me to pick a file to open, not save.
After some google searching, it sounds like it has been depreciated to use a GtkFileChooserButton to select where to save a file. From the mailing list post I found, it sounds like this was depreciated because it promotes bad interface design.
Right now, I can't seem to find the right way to do it though.
So, what is the right way have a user pick where to save a file? What about when they need to be able to pick more than one file?
Sorry if I have no idea what I'm talking about, this is my first time actually trying to do something useful with GTK+ and C.
/* Since You did not provide a version, assuming GTK+3 stable */
Afer a quick look at the GTK+ reference manual, quickly found that the manual says GtkFileChooserButton can only be used for selecting a file or a folder for opening. For saving it suggests using either GtkFileChooserDialog, or GtkFileChooserWidget. Which one fits Your particular situation better, is up to You to decide. Consult with the manual for more info. Also, the whole GTK+ API documentation is here
Actually, it's best to look at the manual first, and only then, if no relevant information is found, try to google it.
I'm Interested in writing gedit-plugins in C. I've checked Gedit/NewMDIPluginHowTo
...but haven't had any luck with it.
How can I get more information about writing gedit plugins in C?
If you're willing to use Python instead, here is a tutorial for writing gedit plugins in Python.
The only tutorial is the one you already found :
Gedit/NewMDIPluginHowTo
I know it can be hard to understand in a first view, but if you read it a few times and give it a try with a basic example, you should be able to achieve getting results quite fast.
Is there something specific that you don't understand?
You can also download some examples of plugins available in C:
https://gitlab.gnome.org/GNOME/gedit/-/tree/gnome-2-30/plugins
Well, you can always email some of the core Gedit developers about your question, I'm sure they have something to give. Try find them via Gedit: Help>About>Credits.
Good luck.
Which configuration management tool is the best for FPGA designs, specifically Xilinx FPGA's programmed with VHDL and C for the embedded (microblaze) software?
There isn't a "best", but configuration control solutions that work for software will be OK for FPGAs - the flow is very similar. I use Subversion at work and git at home, and wrote a little on 'why' at my blog.
In other answers, binary files keep getting mentioned - the only binary files I deal with are compilation products (equivalent to software object and executables), so I don't keep them in the version control repository, I keep a zipfile for each release/tag that I create with all the important (and irritatingly slow to reproduce) ones in.
I don't think it much matters what revision control tool you use -- anything that you would consider good in general will probably be OK here. I personally use Git for a sizable Verilog + software project, and I'm quite happy with it.
What will bite you in the ass -- no matter what version control you use -- is this: The Xilinx tools don't generally respect a clean division between "input" and "output" or between (human edited) "source" and (opaque) "binary." Many of the tools like to store some state information, like a last-run time or a hash value, in their "input" files meaning that you'll get lots of false changes. Coregen does this to its .xco files, and project navigator (the main GUI) does this to its .xise files. Also, both tools have a habit of inserting or removing lines for default-valued parameters, seemingly at random.
The biggest issue I've encountered is the work-flow with Coregen: In many cases, at least one of the following is true:
You have to manually edit the HDL files produced by Coregen.
The parameters that went into Coregen are stored somewhere other than the .xco file (usually in what looks like an output file).
You have to copy-and-paste the output from Coregen into your top-level design.
This means that there is no single logical source/master location for your input to the core-generating process. So even if you have the .xco file under version control, there's no expectation that the design you're running corresponds to it. If you re-generate "the same" core from its nominal inputs, you probably won't get the right outputs. And don't even think about merging.
I suggest CM tools that support version labeling and binary files. Most Software CM applications are fine with ASCII text files. They may just store a "difference" file rather than the entire file for updates.
My recommendations: PVCS, ClearCase and Subversion. DO NOT USE Microsoft SourceSafe. I don't like it because it only supports one label per revision.
I've seen Perforce and Subversion used in a couple of FPGA-intensive companies.
We use Perforce, and its great. You can have your code that lives in Linux-land checked in side-by-side with your Specs and Docs that live in Windows-land. And you get branching, labels, etc.
I've seen everything from Clearcase to RCS used, and it is really all okay for this kind of thing. The important thing is to get a good set of check-in policies established for your group, and make sure they stick to it.
And have automated nightly regressions. That way, when someone breaks the rules, they can be identified and publicly shamed.
I have personally used Perforce, Subverion, git and ClearCase for FPGA projects. Since VHDL and C are just text files, any works fine. However be sure to capture the other project and contraint files and any libraries you use.
Also think about what to do with the outputs, e.g. log file and bitstreams. Both tend to be big and the bitstreams are binaries.
Previously I used Subversion but have switched to git two years ago. Git handles FPGA design files just as well as it handles every other text and binary file. Git is all you need for version controlling your files and artifacts.
For building the designs, I recommend just using a single ISE project called "ise" (living in a subdirectory called "ise/"). You can take a look at my (very modest) FPGA open-source project on github for the file layout. I don't bother storing the ISE files at all since they are easy to regenerate. The only things I save are the Verilog files and some ISIM waveform config files. In other projects that use coregen I save the coregen.cgp project file and all of the *.xco scripts for regenerating cores. Then I use a Makefile for actually running coregen on the *.xco files. There are a few other Xilinx-specific files you should version control too: *.ucf, *.coe, *.xcf, etc.
I experimented with using Makefiles and the Xilinx command-line tools but found that ISE did a much better job tracking dependencies and calling the tools with the right arguments. Just don't make the mistake of trying to version control your ise/ project files or you will go mad. Xilinx has something like 300 different file types which change every release. If you want to save a file, you can try the ISE project file itself with a .xise extension. Anything that is hard to recreate, like the golden bitfile that you know works and took 6 hours to build, you might want to copy that and configuration manage it explicitly.