First GUI version of Emacs - user-interface

The first versions of Emacs ran on text-only consoles. Currently, Emacs can be run in text-only mode with the -nw parameter. When was the first GUI version of Emacs released? Was it GNU Emacs?

For GNU Emacs, the earliest mention I can see in the NEWS files is in version 18, which appears to have included some form of X support from the outset.
That pre-dates Lucid and also Epoch (from which Lucid was derived).
Indeed, Epoch is described as:
a set of patches to Emacs 18 that gave it much better GUI support (Emacs 18 was very much a tty program, with GUI support crudely grafted on as an afterthought.)
so clearly there was some GUI functionality present already at the time that work began.
Unless there was some lesser-known fork that went down this path prior to 1986, it would certainly seem that GNU Emacs was the first to include GUI support.
This is based on Jamie Zawinski's very informative timeline and history:
http://www.jwz.org/doc/emacs-timeline.html
http://www.jwz.org/doc/lemacs.html

Related

Are the UNIX Command Line Tools like Cygwin exactly the same as real Unix/Linux?

If there is no difference, then I can just install Cygwin on my Windows 7 PC, and seems there's no need to buy a Macbook (as I can use UNIX command line already).
Yes there are differences. You just have the basic commands like cd, ls etc but of course nothing compared to a real operating system.
You can read more about what is or not Cywin at its homepage:
https://www.cygwin.com/.
No - the Cygwin FAQ lists a number of differences from Linux/Unix.
It does share one difference with OSX versus almost every other system: as a rule, the underlying filenames are case-insensitive but the tools lack flexibility to deal with this except for special cases (though for both, case-sensitivity is being offered as a feature now).
The Cygwin FAQ mentions this. OSX has supported it for a while, though it is not the default (see MAC OS X: How to determine if filesystem is case sensitive?).

Cross platform make replacement

I am hoping there are some Windows command-line wizards here. If there are, I am forever in your debt.
I have used R (and related tools) on Linux for years. I do everything in emacs if I can. My fingers are just happier that way.
To ensure my analysis is reproducible, I write a makefile for each report / analysis in a project. I use a combination of R and pandoc to produce reports these days. Once my makefile is written, I simply open a shell and enter:
make -f my_target
And my computer runs my analysis. Easy. On Linux.
I have recently started a job with the government and my computer is running Windows and I no longer have make, except through mingw and neither emacs nor gitbash recognize make. I would like to be able to run make (or something equivalent) from both (or either) emacs / gitbash to run my code in a coherent / sane manner.
Thus my question is this. How can I use make, which is currently ONLY accessible through a msys shell and not connected to either gitbash or emacs or what other tool should I move to so I can continue to "build" my reports in a sane / reproducible manner?
If I am better off learning a new tool, that is fine. If there is some way to run mingw's make from emacs / gitbash that is good too. I am open to suggestions. Most of the tutorials on-line are for Windows programmers moving to Linux. There aren't as many resources for us moving from Linux to Windows (which is understandable).
After much swearing and gnashing of teeth, I finally figured out what I did wrong.
I followed the installation instructions for MinGW, but I made a typo when I altered my user's path. Thus, MinGW was NOT in my path.
Following these instructions work, but it isn't smart enough to fix your typographical errors.
Getting Started

Octave output buffer completely messed up on OS X. How to fix?

I have just installed Octave 3.6 version on my MacBook. It uses emacs as its default editor, but it seems some regular emacs keys (such as C-x C-c for exiting) doesn't work in Octave emacs. Also, the output buffer gets completely messed when I try to use octave. Also, it always prints the prompt even when I'm in emacs. (See picture below)
It seems it's parsing my input in the editor on the fly. But I have no idea how this could every happen.
Can anyone tell me what the problem is and how to fix it?
My guess is that you end up running the Emacs that comes bundled with Mac OS X (an old version of Emacs that only works in text mode) and you want to change that by installing a more recent version that can run in the GUI. But that's just a wild guess.

How can I most effectively use Emacs as an editor alongside XCode?

There are a few tutorials online (For example) having to do with configuring emacs to work with XCode, but they all seem to be for old versions, and I haven't found one that ties neatly to XCode 3.x + Emacs 23.1 in a way that I can unpack.
So, I'm running XCode 3.1.2 and the Mac Cocoa application build of Emacs 23.1. I have a passing familiarity with elisp, so modifying configurations doesn't scare me, particularly. I'd like to be editing my Objective-C code in Emacs, because the XCode editor is painful once you've used a real text editor (snark, snark).
What should I do to make this happen?
For Emacs.app you can adopt a cleaner approach, and it doesn't require you to change configurations (unless you don't like make-frame to be called when a file is opened from XCode, but it's very easy to change).
Well, the customization should be similar to the documentation you pointed to. With Emacs 23, the server/client code has changed just a little. Namely, you can start it with the [--daemon][1] option to have Emacs start a server in the background. Then, have XCode just call Emacs using [emacsclient][2]. There are options you can use with emacsclient to force a new frame (graphical window): -c, and you can even start it off with -a to ensure you get an emacs if you forgot to start it with --daemon.

Do the vi and emacs implementations for Windows behave like their Unix counterparts?

If not, what are the significant differences?
Edit: Daren Thomas asks:
which ones?
I use gvim on Windows and MacVim on the mac. Seem similar enough to be the same to me...
By which ones, I'm guessing that you mean a specific implementation of vi and emacs for Windows. I'm not sure as I thought there were only one or two. I'm looking for the ones that are closest to the Unix counterparts.
I use GNU emacs built for Windows, and have found very few, if any, differences. There's the option to load your .emacs file from _emacs or .emacs (although .emacs works fine on XP and above). You can configure it to use Windows-style or Unix-style line endings by default (which I suppose you could do on a Unix system too...).
You may want to tweak such settings as Emacs's startup directory and home directory. To do the former, modify the shortcut that starts emacs. To do the latter, add a HOME environment variable - this will control where your .emacs is loaded from. For more information, check the always-excellent EmacsWiki's MsWindowsInstallation page.
which ones?
I use gvim on Windows and MacVim on the mac. Seem similar enough to be the same to me...
GNU Emacs has long been working natively on Windows as part of the main source, and can be compiled with Visual Studio (you can also find some pre-compiled binaries). As far as I know, there are no significant differences.
There are quite a few vi clones (e.g. vim) and also various Emacs implementations (Gnu Emacs vs. XEmacs spring to mind).
These clones differ on Unix themselves and will thus also differ on Windows.
One thing I found with vim is that the directory structure for plugins etc. is very different on Windows - ~/vim.rc translates to %HOME%\vim_rc (or similar, depends on stuff I don't understand), vim tends to save stuff like plugins under C:\Program Files\vim\... instead of ~/.vim/...
The Windows versions typically use the same base source code as the "regular", Unix-based versions. There may be sections of the code that are specific to Windows, just as there are sections specific to certain flavours of Unix. In general, though, the Windows versions of these packages will behave identically to the Unix ones, except where this is not possible (for example, gvim in Windows will use Windows GUI elements, of course).

Resources