Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
My internet connection is extremely slow and therefore I execute batch files on the server without GUI, i.e. directly from the terminal. However, oftentimes I need to make a few changes in the code and a text editor highlighting Stata syntax would not hurt. Is there one?
Sublime Text editor has a package for Stata. If you're using mac you can find installation instructions here.
As linked by Maarten Buis, Nick Cox's list is the reference. It's a cool list, but it's badly outdated and therefore misses out the best parts of Stata support on Mac OS X. Here are some additions that also allude to the other answers.
Mac
TextMate has two Stata bundles, the Beatty bundle and the more recent Schumm bundle that uses a smarter approach to Stata syntax. (Note: not sure whether the Beatty bundle works under Stata 13; the Schumm bundle, which is the one you get through TextMate's bundle settings, does.)
Two other editors, Chocolat and Sublime Text, support TextMate bundles or ports of TextMate bundles. Phil Schumm's Stata bundle for TextMate is the most advanced and up-to-date solution that I know of, so I'd recommend that if you need an external editor.
TextWrangler also supports Stata through its own plugin system. I guess that BBEdit might therefore support it too, probably through slightly more awkward AppleScript calls. The only reason I see to use these instead of TextMate is if you are running an old system and/or are using these editors already.
If you need more alternatives, check out websites like Alternative To, I Use This, MacUpdate or VersionTracker for a larger choice of options. You'll find out that SubEthaEdit and Smultron (and probably its deceased fork, Fraise) support Stata, for instance.
tl;dr On Mac OS X, use TextMate with the Schumm bundle, and you will like it. (No idea if you can create GitHub issues through email, though!)
Win
Notepad++ has support, and there are mentions on Statalist of PFE, UltraEdit and WinEdt also having support. My guess is that you will find it more useful to get Sublime Text and use its Stata bundle port, unless again you are already using these editors.
tl;dr On both Mac OS X and Windows, Sublime Text with the Stata TextMate bundle port seem to work well.
As mentioned in another answer, Vim also offers support, and Emacs has an ado major mode, plus some additional functions through ESS (Emacs Speaks Statistics). Finally, if you are looking a Java cross-platform solution (but why would you?), jEdit supports Stata syntax.
If you want support for Stata colored syntax everywhere (e.g. on GitHub), you'll need to write a lexer for Stata and submit it to Pygments. I've asked a question about that. It does not look very difficult if you know enough Python (which I do not and regret).
HTH
Added: links, sections.
Unsurprisingly, Vim supports syntax highlighting for Stata out of the box. See http://www.vim.org/scripts/script.php?script_id=440 and this blog post:
http://www.enoriver.net/stata/2010/02/26/i-switched-to-vim/
Similar to the other folks, my recommendations are Sublime Text and TextMate. They're my favorite editors on Windows and Mac, respectively. If you're a Mac user, I recommend TextMate (It's free, but Sublime Text is not).
You asked for a text editor, but if you also use any HTML editor, you can use Statax useful. (Here is the link to Statax, if it interests you).
This question was asked years ago, but I would like to add another option that is probably already known to more experienced Stata users. However, this may not be the case for new programmers who end up here, perhaps through a search engine, looking to find more information on the topic.
Visual Studio Code is a streamlined code editor, which offers a very flexible environment for programming. Once installed, one can obtain the necessary add-on package for Stata syntax highlighting from the Visual Studio Marketplace. It is regularly updated and the user can expand its functionality using extensions. As such, if someone is programming in more than one language, s/he can keep everything under one roof.
This solution addresses the OP's need to edit files remotely through its built-in Git support. Git is now pretty much the standard in version control. The idea behind it is that one does the work locally and then syncs the copy of the repository with the copy on the server.
Although this is not a command-line solution, i think it provides a great cross-platform development environment. And Git itself has proven to be very fast and reliable.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have heard from my peers on more than one occasion that it is "advised" not to do version controlling of your code from within the IDE where you write it. I have seen them developing on Eclipse, IntelliJ IDEA, etc. but doing version control (in my current scenario - Git) from command-line or standalone clients as opposed to using the corresponding plugins readily available for the IDE.
Though I have used version control plugins in Eclipse and never found any issues, I would like to know what is the general norm and why?
I don't think that there's a general norm. The answer to the question is highly subjective.
I personally don't use any IDE integration (not even a GUI tool, except the builtin ones git gui and gitk) because my experience told me that these tools behave different than the command line version and/or don't provide the full functionality available on the command line:
Does NetBeans ignore my Git pre-commit hook?
Can you interact with the index/staging area with TortoiseGit?
Does TortoiseGit actually make Git a lot easier to use like TortoiseSVN?
Another thing is that your knowledge about your versioning tools is bound to your IDE. Maybe you want to set up some version management for other things than the sources you edit with Eclipse (your dotfiles, for example).
Or one day you switch your IDE, drop Eclipse and start using Visual Studio. Then you don't have to learn only Visual Studio but in addition you need to learn the Git integration in VS too.
I think compared with what I've written above, there are no serious advantages that would legitimate the usage of version control tools from inside the IDE.
So, IMO, it's a bad practice to do version control from inside the IDE and it should always be done from the outside.
You should always try to use the right tool for the job, and that is a personal question so there is no "norm" or "good practice".
In my case I prefer to use a ...
GUI, like Sourcetree, for viewing logs, diffs, staging/discarding lots of files, staging/discarding hunks, etc.
CLI for modifying remotes, squashing commits, pushing, cloning, etc.
Also, if you plan to break out of the box a little bit, it wouldn't hurt to know a little bit about the Git internals.
Those plugins and add-ones tend to sometime do things that otherwise you wouldn't do if you were using the native (CLI?) client.
For example, if you were working with an Eclipse + ClearCase plugin, any change in a file, even adding a new line, will initiate a check-out operation (depending on the configuration).
Specifically for Git, you should be aware of its internals to properly work with it. Using the IDE hides those things from you. In normal trivial operations, it will work. But, when you are facing a source control issue (ugly merge, cherry-picking, rebase conflicts) you will have to go to the CLI to resolve, but then you have no idea what were the actual commands that the IDE ran that got you to this situation in the first place (plus you have no experience with the CLI at that point).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Emacs and vi are the traditional editors of the programming gurus. But, have any modern editors been able to displace these two in terms of extensibility and text editing productivity?
I know editors such as Eclipse and commercial editors provide language specific advantages such as intellisense and refactoring, though this is not quite what I'm looking for. My question is more along the lines of an innovative editor paradigm at a more general level, such that I can use it for many disparate languages, extend it for other tasks, etc.
Sublime Text is a relatively new and very good editor for Windows.
www.sublimetext.com
a more general level, such that I can use it for many disparate languages, extend it for other tasks
On Windows, the Zeus editor can be configured for almost any language and is also fully scriptable making it easy to extend.
How about Yi? My impression that its community is currently targeting the Haskell hacker, but is supposed to be like Emacs but based in Haskell rather than Emacs Lisp. Not quite mainstream, but is the kind of editor you're inquiring about I think.
I'm really surprised no on has mentioned these two yet:
TextMate (Mac)
E Text Editor (Windows) (it recently gained vim features, but I wouldn't call it innovative).
Actually most functionality of both editors can be replicated in vim, and I'm sure in emacs, too.
My question is more along the lines of
an innovative editor paradigm at a
more general level, such that I can
use it for many disparate languages,
extend it for other tasks, etc.
The web browser is or will be the ultimate editing tool that can be extended, customized, that is always connected and have all kinds of applications... Pretty much everything can be done through a Web Browser.
As Jeff Atwood said, Firefox is an IDE. With it, and some extensions, you can transform Firefox into the Visual Studio of browsers.
Any web page is an extension of this new kind of "editor". That's why, for example, Google uses it as the main component of an OS (like Chrome OS). The current trend is to do everything on the web.
Eclipse, Visual Studio and friends are IDEs. Emacs and Vi are text editors. A text editor makes just one component of an IDE. Editors that come with most modern IDEs provide an Emacs or Vi mode. (Here is an example). The other way round, Emacs and Vi could be easily extended into a full IDE. (For instance, look at JDEE).
Wikipedia's comparison of text editors.
I've tried UltraEdit, Notepad++, Komodo and a bunch of others and for my money Editplus is the best of the bunch but it's really a matter of personal taste - what annoys you, what features do you enjoy, etc..
I think that the answer to your question would be JEdit, UltraEdit, KomodoEdit, Geany, TextMate, NotePad++, Kate, Gedit. I've used some of them at some point before I finally chose to stay with Emacs for all eternity. All those editors except TextMate and UltraEdit are open source and I personally enjoyed a lot KomodoEdit for web development. It also had an nice extension API based on XUL and JavaScript.
The general advantage of this batch of "modern" editors it that they have better support for modern GUI toolkits and better builtin "intellisense" features. None of them, however, is as customizable or as extendable as Emacs and Vim. You won't be able to do terminal text editing with these editors either.
As an example of what you can do with emacs, I just figured out that you can run the git mode magit transparently over ssh and thus interact with a remote repository! Way cool! I have yet to found another editor with that kind of extensibility.
I usually stick to emacs, even though (quite obviously for most people) i cant use it to its full potential. Past week i had to work on a pc with notepad++ installed, so i tried it and liked it very much. It feels "comfortable", i think, still it cant beat the "raw power" of the classics.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
As some of you might know I am the lead developer of Padre, The Perl IDE. In the first year of its development, Padre became an acceptable text editor with some extra features for Perl development.
I'd like to ask the Stack Overflow community for some help in driving the project further to turn it into an exceptional IDE for Perl development. So I'd be glad to read what do you think are the most important features of an IDE that are still missing from Padre?.
Especially I'd be interested in people who currently use Eclipse+EPIC, Komodo, Visual Studio, or any of the text editors for programmers.
The most important feature of an IDE for Perl development (including Padre) is:
an interactive debugger that actually works. E.g. remembering breakpoints, ability to drill down into complicated data structures, and copy (to clipboard) should work on watched variables - including a menu command Copy Special that allows putting it in various formats; say CSV, XML or tab-separated.
The two most invaluable features I find:
line-by-line debugging, watchpoints, breakpoints, and so on, so I can properly debug my code.
code completion so I don't have to go looking up docs (even online).
OK, here's my third answer, although I hate to say it.
The competition is pretty easy to install. Padre isn't. I tried to update to the latest release today and, once again, got failing tests.
I am a heavy Perl EPIC user and my biggest gripe is not being able to jump to a function that is clearly defined in the current context (usually by pressing F3). It is pretty
much hit or miss at this point.
Stability. People turn away quickly if their editor crashes and they lose their work.
I work with Komodo. I also use other editors but I come back to Komodo most of the time. A good IDE shoud have:
A good Debugger. Breakpoints, watch lists, everything you need.
Remote debugging. Threads debugging capability.
Syntax highlighting including weighted fonts as well ( I was pretty disappointed by Oxygen, for example, an XSLT IDE, where I can not use bold fonts to emphasize reserved terms)
Syntax completion.
Project management tools, preferable extendable by plugins.
Good VCS integration. This is something that I absolutely love in Eclipse: You instantly see what files have local changes and which aren't added to the repository yet. And you get to browse the different versions and have a nice diff view just one mouse click away.
A project manager. It's essential for me to be able to define the set of files and folders that comprise a particular codebase. Sessions are useful but not a replacement.
Testing integration.
Perl has great unit testing tools. When I run my test suite and get a failure, I want to see the code for the test that failed.
Having a good way to jump through test results and see the code for the failed test along with the expected and actual results would be a great boon.
The first thing I look for is some kind of overview of the currently active file. I'd like to see methods/functions and, if possible, the used modules and especially any use base statements.
You solved that pretty well in Padre.
Visual-Studio style refactoring for variables and function names and extraction of functions.
Visual studio searches your whole module for all references and allows you to see all changed lines in case you do not want to change one instance (for whatever reason)...
The question seems more debatable than answerable.
Risking myself of being accused copyright abuser, I will post contents that I remember from the book "Interactive programming environments" by David R. Barstow, Howard E. Shrobe, Erik Sandewall.
It will not be exactly the same, as I have read the book many years ago and I've jotted down it in another language.
PRINCIPLES OF A GOOD INTERACTIVE PROGRAMMING ENVIRONMENT
1: Know the user
+ Know the previous knowledge and practice of the user
2: Minimize the memorization
+ Selection and not characters entering
+ Names and not numbers
+ Predictable behavior: the user should have a previous impression of what the system will do
+ Possible access and changing of the parameters of the system
3: Optimization of operations
+ Fast execution of common operations
+ Inertia of visualization: the screen should change the less possible
+ Memorization of system operation in user's memory
+ The meaning of specific operations should have a simple relationship with the state of the system
+ The system must be prepared to accept more than 10 followed commands per second, so that it can operate on the user's muscular memory
+ The system should be prepared to organize the parameters of a command
4: Engineer for the errors
+ Provide good error messages.
+ Engineer it to remove away the common errors.
+ The system should provide reversible actions.
+ Redundancy: the operations should have more than one way of being done.
+ Integrity of data structures.
The ability to configure and run external (command-line) tools. Plug-ins are great but end-users won't necessarily want to author one just to integrate with an external tool. Allowing users to configure their own tools provides a great deal of extensibility with minimal barriers to entry.
My editor of choice is UltraEdit. It's not an IDE, but through its support for user tools, I've been able to integrate IDE features such as lint, version control, debugging, and more.
This can be possibly achieved via use strict; but could be as well a valuable feature even if not use'd explicitly, namely:
the other day we spent about 10-20 minutes debugging the following behavior:
my %hash;
$hash->{'key1'} = value1;
# on reading in a different module
print $hash{'key1'}; # is, of course, empty, but was so easy to overlook in the code above
resume:
proper Perl type safety brought in by the IDE.
It might be already implemented in Padre, though, as it turned out not in Eclipse+EPIC
I use emacs. I would like a system that helps me refactor code, especially when I'm working on ugly 1999 code that uses the begin-at-the-beginning-go-to-the-end philosophy combined with duplicate-and-modify.
I looked at Eclipse, but I can't work with a system that requires me to create a project before I can make a one-character correction to a file.
I looked at Padre, but it's slow and crashes.
I looked at Kod which claims to be configured by CSS, but I can't find a man page that will tell me where to put the CSS.
Integration of a read-eval-print loop. As a heavy Emacs user, I very much appreciate Sepia. Very useful for trying things out before I commit them to code.
Ability to create and debug XS code.
The ability to use my own choice of editor (which it may have, as far as I know). That has a chance of winning over the vim/emacs people.
I don't know if Padre can do this, but the ability to split the screen is very important to me. As a VIM user, I constantly split my screen to look at another file while coding.
Line ending policies for files, by directory, and project-wide.
So, for a given project or directory, I'd like to make all line endings be LF only. While in another directory I may wish to have a mix of CRLF and LF files.
I work a lot on stuff that goes back and forth between Unix and Win32 environments.
The typical solution of automatically converting all files back and forth as one moves from platform to platform hasn't worked well for me.
When a file gets created in the wrong format by accident, it can be a real pain.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Emacs is great. To me at least, Emacs is a metaphor of all software. Still, I know that it lacks some features sometimes that you have to actually migrate to other environments. Given emacs is so customizable, and great and everything, we only have to wish for it right? What do you think is a feature that emacs lacks right now?
Note: As of Emacs 23, there is support for M-x butterfly.
There is a wishlist on EmacsWiki.
I'd like to see a better package manager for emacs. Perhaps something like RIP? ELPA looks interesting, but I don't like that it's trying host and consolidate all the packages. I'd prefer to be able to add modules from any git or cvs repository I find. I'd also like the modules in this theoretical package manager to have a standard way to include icons and info file. Finally, I'd like it to have a dead-simple method of compiling all modules.
I've tried to modularize my emacs files in this style (see my github emacs.d repo), though I'd happily ditch it if something better gained widespread support.
An implementation of elisp that's not 1985's state of the art. I mean, seriously -- global variables everywhere? A non-reentrant parser? It's like they don't want people to work on it. I briefly looked at adapting Emacs to be a shared library, but I couldn't get past even parsing elisp files.
I wish a standard code sense autocompletion(hippie-expand is some kind out of date), and a better GUI to support such things as the flowing completion candidates list which should be no worse than that of VIM.
Well, since Emacs is moving to guile, meaning modern lisp is imminent, the only things I want is the ability to add buttons somewhere. A button browser, or a toolbar buffer would be nice.
On the other hand, one of the best things about emacs is that it doesn't populate your screen with just about anything.
However, the ability to for instance, make a JUnit testing buffer in it's own buffer, etc. would be great. Perhaps forcing button buffers being in it's own frame of something (a new type of frame, like GUI-frame or something?)
Oh, and better rendering capabilities, and a flash plugin so we don't have to start a separate program just to browse the web.
Edit: By "imminent" I mean imminent as in geologically imminent.
Since you have C-x M-c M-butterfly, you really don't need much else.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
The people writing the user manual are not necessarily programmers, and they need a visual editor. A major issue is the internal format of the authoring tool; it should be readable text/html, so it's easy to compare versions of individual pages checked into version control.
DocBook
(source: docbook.org)
Microsoft HTML Help Workshop can be used to create good quality professional CHM help files. All you need is a bunch of HTML files. The tool "compiles" all these and bundles into a single Help file.
The HTML files can be generated using Microsoft Word/Frontpage or even Dreamweaver. You might want to consider source controlling these HTML files.
Latex. Lyx provides WYSIWYM for writing latex files.
At my old job they used a tool by madcap software called flare.
It seemed to work really well.
There are other professional products which allow help file writing and they have support of "context ID" which makes context sensitive help possible. Doc To Help and RoboHelp are these type of products.
A good combination to consider is Subversion, DocBook and Publican.
Version control = Subversion
Content Authoring = DocBook
Publishing = Publican
Optional WYSIWYG = Serna
At the moment, this is one of the toolchains in use by the world's largest provider of open source solutions, and the name behind much of the world's use of Linux-based operation systems in the enterprise market. Most (and close to all) of Red Hat's official documentation is created in such a manner. Same goes for Fedora.
The major "pro" here is that these are freely available tools, with a strong overlap in the market of technical writers. All of which will be able to (but might not want to) write in XML, and picking up DocBook is like picking up HTML in the 90's. Subversion is a very common version control tool, that like DocBook is relatively easy to implement and use. Publican is a great publishing tool that can take DocBook XML, and publish it to PDF, HTML, HTML-single, etc. Obviously your writers can use a WYSIWYG like Serna, but I use snippets in Geany (on Fedora) or TextMate (on OS X) personally.
The major "con" is the perception of technicality. Your writers might want WYSIWYG (and can have it), and depending on your documentation needs, this might be what you end up using. As you would know, there's a market out there for "Technical Writers" who specialize in fixing Microsoft Word styles (and markup), so the arguments for separating "authoring" from "publishing" are based on proven but distinct use cases for organizations that require documentation to be held up to the same standards of the engineering/programming/source production.
Some of the extreme advice you will get comes from people and companies that have been exposed to the value of XML documentation, and especially those in the realms of DITA, where certain multi-nationals have a reputation for acquisitions that are influenced by the format and availability of the product knowledge. there are also the arguments that locking your documentation into a "sticky" or closed format doesn't help the future maintenance requirements. This is where the open source options gain support on a corporate level. Plus, obviously, it's free.
You can use Subversion and MGTEK Help Producer. Help Producer makes help files from Word documents. TortoiseSVN comes with scripts to compare different revisions of Word documents, in Word itself (Word has a version compare tool).
Your users are going to want a visual diff tool that resembles the one they are editing in. If they are just slightly not-technical, DocBook or Latex aren't going to work (I've tried giving my users both, and I even tried Epic Editor as a DocBook editor which is very expensive but didn't work out very well after all). Sticking to something they know (Word) will prevent you many headaches.
I was very reluctant to go this route at first too, because I wanted a solution that was more 'technically perfect', but I realized over time that having happy and productive users was more important. Just saying that I know where you're coming from, but try the Word route - it works much better in practice than all the 'pure' text-based solutions that are out there. Regular users don't like markup based editing.
If you're using Visual Studio, take a look at SandCastle - http://www.codeplex.com/Sandcastle.
There's also a couple of tools that help you build sandcastle files, try searching "sandcastle" on codeplex. One of them is SandCastle Help File Builder (http://www.codeplex.com/SHFB), but I've never used it so I don't know if non-technical users will be happy with that.
Mapcap Flare is the best commercial tool around. Written by the ex-developers of Robodoc
I created a documentation system called Mandown (Markdown/Html/Javascript/file-based relatively linked documents for portability) which would easily go under version control. The visual editor part you would have to figure out separately - I sometimes use HTML-Kit which at least has a preview feature.
See What is the best way to store software documentation?
Here's another tool to check out: Xilize
We are using APT. It integrates well with the CI (standard build artifact) and is more alive than for instance word document. It is also possible to generate PDFs and other formats when needed.