Neat! I'll have to try it out, see what it does for me. I have been thinking about how to add profiling or something like Emacs vhdl-mode's SmartBar but it's a fairly major project so I have only done some preliminary mental design work. This might do the trick ahead of time.

Would also note there are multiple VHDL plugins now, and at least one (mine) has an updated sublime-syntax file for the language rather than the Textmate one.

Cool. Let me know if you need any help setting it up. Not sure which vhdl plugin is yours, can you add a link? The one I have been using is 5 years in the making and has ongoing updates. https://packagecontrol.io/packages/VHDL

I am not too familiar with emacs. I'm guessing you meant speedbar though. I think with this plugin you should be good to go. ST3 already has built-in a GOTO anything to easily navigate to functions etc. based on the syntax file. It also has built-in a way to navigate to types or subtypes (using the copied syntax package) in other files in your project.

What ST3 didn't have was a way to navigate your project hierarchically. Also much needed was a way to navigate between your hierarchy and the file system without having to dig through in explorer for example. Also, ST3 has a powerful build system which I have harnessed to link directly to fpga build tools (Vivado or Quartus). You can use this to elaborate your rtl, verifying syntax for example, within ST3. The tcl scripts are extensible too. So, with Vivado for example, you technically have access to the entire tcl command line within ST3 with the hdlproject plugin.

Vivado and Quartus text editors hover between unusable and just enough depending on who you ask. My intention was to replace the need for these GUIs with ST3. If you are doing floor planning or checking schematics, then yes, use their GUIs. But most of the time is spent writing code and building, which I hope can now all be done within ST3 with hdlproject.

Yes, speedbar. I don't use it a great deal but once a project gets to a certain size, it's actually useful in some respects. I am/was primarily an Emacs user but I'm often in Windows due to EDA toolsets and I can use it there, but I have a hard time convincing colleagues that there's benefit to the vhdl-mode aspect of it. I thought maybe ultimately Sublime would be a better gateway drug to good HDL editing.

And yes, the built-in editors are terrible. I'm not even particularly fond of Eclipse though Sigasi's Eclipse plugin for VHDL is supposedly pretty great. It's also hideously expensive.

My VHDL plugin is at https://packagecontrol.io/packages/VHDL%20Mode. It differs from the older one in that I wanted to replicate the features from Emacs vhdl-mode that I used the most (namely port copying and pasting, nice header updating, and code beautification.) Along the way, I decided that the syntax definition that had been handed down over the years was just not really up to my standards at least. We've got a very powerful lexical scoping engine and it was doing the basics. So I tried to improve upon that, and along the way, we get slightly nicer color scheme support (mainly using entity.name and storage.type and variable.parameter).

Anyway, it's there. Now I need to consider whether to worry about project outlining support or just suggest using yours. Only thing I can see in your architecture (and it's ENTIRELY opinion i.e. do what you want because I'm a nobody) that I would tweak is instead of using the Preferences settings for setting up your project, Sublime already creates a project file and it's possible to use that. I kind of ran into that issue with setting up settings for VHDL Mode and hit upon a solution that I thought was generally non-objectionable where I created some basic settings for defaults and then permitted a project-by-project override, though I did have to write my own settings retriever for this because package settings don't flow into the regular Preferences settings hierarchy. But in the end, I liked the result. I would expect project definition settings to be in the project file. But, I need to give it a shot and tinker with it, see if it's something that I'd get use out of.

Thanks. I'll give your syntax a try. I initially tried to do the hierarchy with a ST3 project file, but it is not configurable enough. So I resorted to symlinked files for now. One slight drawback of this is you need to run ST3 in admin mode, on Windows, to make full use of the plugin. But it works without any special privileges on MacOS and Ubuntu.

The file system that is created is also symlinked. My idea was that it would only contain directories that relate to your project. If there are files or folders that don't contain vhdl or verilog, but you still want in the sidebar, you can add these to the "files" or "folders" lists in the preferences file.

While making the plugin, I have tried to go the Sublime way in the sense of going along with their intended flow. So I have used the preferences file to define any settings related to the plugin. Commands can be accessed through the command palette, the project menu, or context menu. The on_hover command is used to provide pop-ups. A single build entry point is used with a drop down to select any of the provided or user-created tcl scripts.

If you're working on multiple tasks in parallel, multiple projects can be created or reopened in separate windows in parallel. Windows/projects can run any of the build commands in parallel with each other.

A simple way of importing larger projects is to use vendor created tcl. It supports Vivado and Quartus project tcl files. If you export a project tcl through their GUI, you can simply include this one file in the "files" list, and that's all you need.

Actually, now that you mention it, I can see, if you weren't using the vendor tcl to source your project, and you had multiple projects going -- the preferences file could get fairly big.

I don't think it would be too hard to add the option of specifying an external myproject.json within the current structure, say external_json_path or similar. This way, the preferences file would stay small, even when there are several projects. In addition, your external project file could be stored in a repo if needed. I think the external json project would be a mirrored structure to the way it's currently setup in the preferences file. I can look at adding this in the near future.

Yeah I didn't mean the actual structure you set up. Using symlinks as an interface into the sidebar panel is clever. Would be nice if we had API to put arbitrary content into the sidebar as this would make your life a lot easier, but for now it works.

No, all I really meant was just the settings. The directories and whatnot that comprise the project I feel should probably go into the project file however I'm personally a big stickler for compartmentalization. Of course, that being said, all of Emacs vhdl-mode project stuff went into .emacs so... I suppose it really doesn't matter THAT much

I did try out HDLProject for a bit but I had to uninstall it pretty quickly. It REALLY doesn't like VHDL files that are not part of a project. I think that's probably not a good behavior in general because even if I'm working on a project I have side files and tests and unrelated things frequently (or even just open up a colleague's source file to check on something that he's struggling with.) If it's going to pop up a dialog box that complains about not being able to find project information about the file that's pretty much a show stopper for me. Having console logging for not finding anything is great, but the dialog box popup is really distracting, as is the fact that it happens every single time the unregulated file becomes the main view.

As for mine, I hope it works for you! I'd welcome feedback. Package Control says there's about 150 souls out there using it and I've not heard boo about it so I can only think that they're getting some benefit out of it. However, the pessimistic side of me knows that if there is something wrong about it, more than likely there'll just be an uninstall and I will never hear what happened in order to fix it. Feedback is crucial!

I totally agree that feedback is important. I'll give it a try this week.

I agree that the missing file dialogue is annoying. I don't run into this that often just due to the way I keep my projects setup. But I can see how that could make it unusable. In the latest version you can disable the reoccurrence by turning off the signal tool tip. I think by default it's mapped to ctrl-shift-L. I think this is good feedback. I'll come up with a way of informing the user of missing files without the dialogue. Perhaps it should just complete the project as much as possible and treat these files as black boxes. This should be easy to fix

Bear in mind this is early days as far as having input from other users. So there's bound to be some UI issues. The core is all there though as i know people who use this plugin on a daily basis. I'll try to push a fix for this within the next week.

No problem at all. Having a console message is sufficient in my own opinion. It's okay for a plugin to attempt discovery and say "oh hey, this isn't setup for me" but the console is a good place for it to do it quietly. My own workflow is very project based, but I swap projects a lot and I can guarantee that I won't set every single one of them up because I don't need to. Sometimes I'm just inspecting code, sometimes I'm making an alteration that doesn't require major modifications. And we have (unfortunately) no internal standard on how firmware projects should be structured, so if I open some dude's design from the other plant, it's usually a disaster area. (I have some very different opinions on how organized these things should be, in that I think they should be organized.)

ANYWAY, long story, yeah, I suspect anything that's a warning should do so quietly on the console

EDIT Oh and you replied before I finished (doing several things at once and this text had languished for awhile.) I'll have to reinstall and see what the error was. If memory serves, it was just a duplicate of the one that shows up in the console, but a dialog box is very intrusive.

Thanks. I'll give it a shot. I think this may be a good week to investigate these things as I squashed a major bug in my actual project (legacy code is such a pain in the ass, and a prior developer combined a system reset signal with an internal signal that then went on to become the asynchronous reset for a lot of downstream behavior and caused some rare glitches).

Still haven't had an opportunity to really check this out, but I really think I'm never going to be able to create the vhdl-mode Speedbar capability until there is an API for creating alternative sidebar text. So I put a link to HDL Project in my own package README so that folks who want that behavior will know where to go.

Just a quick update: the plugin has moved into a new, licensed, phase to support ongoing development. I’m still learning how to promote it. Have a bunch of ideas for new features. Checkout the new site here: https://hdlproject.com