Wingide is a beautiful application

V

vinjvinj

I haven't used an IDE in a long time but gave wing ide a try because
I wanted the same development platform on Linux and Windows.

I'm currently using Ultraedit and it works fine but needed something
more portable as I'm moving my main platform over to Ubuntu. I first
tried jedit and was reasonably happy with it but it felt slow and it
did not have a native look and feel to it. It was really hard on the
eyes.

I was impressed! The UI has completely changed since the last time I
gave it a spin. It's much more useable and beautiful on the eyes. My
productivity has gone up for sure and would highly recomend it to
anyone else. not to mention you'll be supporting python as well.

Things I like about wingide:
- Ability to double click on the project plan and it hides and you
double click on it and it becomes visable again.
- Ability to double click on the debug/python shell plan and it hides
and you double click on it and it becomes visable again.
- Auto completion is very powerful and well implemented.
- Open the file that a function was defined through the context menu
- Keyboard mapping for vi and emacs
- Always having a python shell available
- An integrated debugger.
- Running in debug mode was significantly faster than any other
debugger I have used.
- Auto indent mode is vary useful.
- The space manager. Notifies you if a file contains spaces and tabs
and then converts all tabs into spaces.
- Ability to debug my cherrypy and turbogears application

Things that could use improvement:
- The block mode Ability to work with text files in block mode where
you can highlight any block in the file. Wingide implementation is
reasonable but not like Ultraedit's or jedit's

Does anyone know what gui toolkit wingide uses? it really is one of the
best applications I've seen for some time and it's a great way to
support python.
 
S

Sybren Stuvel

vinjvinj enlightened us with:
I haven't used an IDE in a long time but gave wing ide a try because
I wanted the same development platform on Linux and Windows.

I use gvim for that :)
- Ability to double click on the project plan and it hides and you
double click on it and it becomes visable again.

How do you double-click on something that's hidden?
- Keyboard mapping for vi and emacs

VI keyboard mapping! I like :)
- Always having a python shell available

I have a Python shell on my PDA, always available :))
- The space manager. Notifies you if a file contains spaces and tabs
and then converts all tabs into spaces.

And what if you want to use tabs?

Sybren
 
S

Steve Holden

Sybren said:
vinjvinj enlightened us with:



I use gvim for that :)




How do you double-click on something that's hidden?




VI keyboard mapping! I like :)




I have a Python shell on my PDA, always available :))




And what if you want to use tabs?

Then you configure it to use tabs. It's a user setting.

regards
Steve
 
J

James

I haven't used an IDE in a long time but gave wing ide a try because
Then you owe it to yourself to also try SPE, PyDev and Boa Constructor
(got off to a slow start, but it looks promising now). All are free,
open source, cross platform, native look and feel and support more or
less the features you list.

GTK.

Two minor peeves about WingIDE.
1.) Not native look and feel.
2.) Auto List members implementation is great. But what about call
tips? Just as important and every other Python IDE has it.
 
C

Claudio Grondi

vinjvinj said:
I haven't used an IDE in a long time but gave wing ide a try because
I wanted the same development platform on Linux and Windows.

I'm currently using Ultraedit and it works fine but needed something
more portable as I'm moving my main platform over to Ubuntu.
This is also where I intend to go, except going for Wing, which is in my
eyes currently no alternative to Ultra Edit as an overall text editor on
Windows ( I am tired of using two or more editors at the same time as I
do when working with Microsoft Visual C++ and want the features of both
Ultra Edit and the Visual Studio IDE ).

- Wing does not have a ruler showing the current column
- Wing has a slow graphics output on Windows (also on Linux?)
- Wing GUI needs adaptation to its logic (e.g. there is no view menue
item). I have to admit, that Ultra Edit GUI is also not good, so both
need some adaptation efforts from the user.
- Wing does not support column mode (as you already said)
- Wing text editing is based on Scintilla and there are many other
powerful and free editors built upon Scintilla available.
- Wing does not support HTML editing by providing separate HTML toolbar
as the last versions of UltraEdit do.

The only thing what makes a difference to me is, that Wing 'understands'
Python code what results in features not available elsewhere (e.g. go to
definition). I don't know if UltraEdit in its Studio version does
similar things - I suppose it does, but I will be surprized if also for
Python - is there anyone who works with it?

The problem with deciding to use Wing on Linux is, that I am switching
to Linux because of its Open Source at no cost feature, so I don't
actually want to spend any money on proprietary software using Linux.
But because there is no Ultra Edit on Linux it can happen, that I have
to reconsider my attitude when actually fully on Linux. But this will
maybe be never the case, as Windows appears to me as a much more
powerful system and Linux comes in only in order to save money (when it
is possible to use Python/Linux for running ready developed Python
applications) on on multiple Windows licenses in case of using more than
one PC.

Why do you go for Ubuntu, not for Mandriva if you are ready to pay money
beeing on Linux?

I first
tried jedit and was reasonably happy with it but it felt slow and it
did not have a native look and feel to it. It was really hard on the
eyes.

I was impressed! The UI has completely changed since the last time I
gave it a spin. It's much more useable and beautiful on the eyes. My
productivity has gone up for sure and would highly recomend it to
anyone else. not to mention you'll be supporting python as well.

Things I like about wingide:
- Ability to double click on the project plan and it hides and you
double click on it and it becomes visable again.
- Ability to double click on the debug/python shell plan and it hides
and you double click on it and it becomes visable again.
- Auto completion is very powerful and well implemented.
- Open the file that a function was defined through the context menu
- Keyboard mapping for vi and emacs
- Always having a python shell available
- An integrated debugger.
- Running in debug mode was significantly faster than any other
debugger I have used.
- Auto indent mode is vary useful.
- The space manager. Notifies you if a file contains spaces and tabs
and then converts all tabs into spaces.
- Ability to debug my cherrypy and turbogears application

Things that could use improvement:
- The block mode Ability to work with text files in block mode where
you can highlight any block in the file. Wingide implementation is
reasonable but not like Ultraedit's or jedit's
As Wing uses Scintilla I don't expect it to support column mode before
Scintilla does.
What about editing large (100 MByte and more) text files? I have
uninstalled Wing already, but I suppose, that it will run into problems
when loading large files what I have experienced longer time ago using
Scintilla.

Claudio
 
J

Jonathan Ellis

Then you owe it to yourself to also try SPE, PyDev and Boa Constructor
(got off to a slow start, but it looks promising now). All are free,
open source, cross platform, native look and feel and support more or
less the features you list.

In my experience Boa Constructor isn't worth bothering with. It's far
too bugy for practical use.
Two minor peeves about WingIDE.
1.) Not native look and feel.

Well... GTK is as native as anything else, on Linux. Even on Windows
GTK apps seem to be spreading; I've been using GIMP and GAIM long
enough that I guess "not quite native" doesn't bug me anymore.
2.) Auto List members implementation is great. But what about call
tips? Just as important and every other Python IDE has it.

Wing shows calltip info in the Source Assistant panel. (Pro version
only, IIRC.)

-Jonathan
 
S

Shalabh Chaturvedi

Jonathan said:
Wing shows calltip info in the Source Assistant panel. (Pro version
only, IIRC.)

However it's not as useful as call tips. You have to switch to that tab.
I tend to switch fairly often to another tab like Search or the Python
Shell. Every time I need the assistant, I have to switch the tab again.

It does step through Quixote PTL in debug mode, which is pretty cool.

Shalabh
 
V

vinjvinj

I have the debug and the python shell just below the editor and the
project and the source assistent on the right pane. You don't have to
swtich tabs when you search or go to the python shell this way. The
source assistant tab is always visible. Since I did not configure it in
any special way, I assume that this is the default configuration.
 
S

sjdevnull

Claudio said:
The only thing what makes a difference to me is, that Wing 'understands'
Python code what results in features not available elsewhere (e.g. go to
definition).

This is something that pretty much any reasonable programming editor
will get you. Vim and emacs both do it.

I get the feeling that a ot of people working with heavy IDEs don't
realize how capable vim/emacs are, so I'll give a brief rundown of what
my Vim environment does for me. (I do Python web development)--if you
don't like the Vi keybindings, the Cream package is Vim that behaves
like a regular modeless editor but with all of vim's power (and a nice
embedded Python interpreter for writing extensions):

1. Python syntax checking: as I'm typing along, if I input a syntax
error then the line is immediately highlighted in red. Useful for
catching brainos like:
if a=1:
(which will highlight in red when I hit enter, point out that I need ==
instead of =).
2. Normal tag-jump stuff: Ctrl-click on a function/method call (or
class or whatever) will jump to the function/method/class definition
(Ctrl-T works as well if you don't like clicking). It keeps a stack of
visited files so you can drill down through your call stack and then
pop back up to where you came from.
3. Python class browsing stuff: A Class menu shows the parent and child
classes of the one you're currently in, and all the methods of the
current class; selecting any of the above jumps to the appropriate file
and line.
4. Interactive documentation stuff: When I type an open-paren, it looks
to see what the prior keyword is and displays help for it in the status
line (preferring Python documentation, then docstrings, then comments
before the function/method/class definition). Even if there's no
help/comments, it'll show the arguments that the function takes. So
if, say, I type:

cmp(

then the status line displays:

cmp(x, y) Compare the two objects X and Y and return an integer
according to ...

If I hit F1 it'll show the full help text. Often the arguments are
enough, and I find the status-line display a lot less intrusive than
many on-the-fly help systems I've seen.

5. A client menu selects which client I want to work in (so, say, I get
a bug report for Client A, I select them from the menu). The Class
menu and other functions respect this (if I'm in the generic Company
class, the Class menu will list Client A's Company subclass before the
subclasses of other companies; if I jump to the Company definition,
it'll go to Company A's client-specific version). It also restarts
development httpd servers on the current machine running with conf
files appropriate to that client.
6. Full version control integration, including side-by-side diff
viewing/editing, etc
7. Editor control on uncaught errors; if I hit a web page on my
development httpd and it throws an uncaught exception, my editor will
jump to the line the exception occured at (preferring a location in the
stack that's in a file I'm currently editing).and I'll have the stack
trace in a scratch buffer if I want it, or as I jump up/down the stack
it'll show relevant parts of the trace in the status line.

There's a lot I'm forgetting, but the basic point is that even "simple"
text editors like vim can easily do a lot of Python-specific niceties
for you (emacs is similarly capable).
 
C

Claudio Grondi

This is something that pretty much any reasonable programming editor
will get you. Vim and emacs both do it.

I get the feeling that a ot of people working with heavy IDEs don't
realize how capable vim/emacs are, so I'll give a brief rundown of what
my Vim environment does for me. (I do Python web development)--if you
don't like the Vi keybindings, the Cream package is Vim that behaves
like a regular modeless editor but with all of vim's power (and a nice
embedded Python interpreter for writing extensions):

I have tried Vim already multiple times in the past and it had always
problems. But what was in the past must not stay this way forever, so I
have got the latest download at

http://heanet.dl.sourceforge.net/sourceforge/cream/cream-0-33-1-gvim-6-3-90-1.exe

and installed it loading my current Python file.

With [Strg]-[End] I went to the end of the file where I wanted to
continue editing, but the syntax highlighting told me there is no code
but only a comment. I checked it and found out, that Vim is apparently
not able to do proper highlighting when jumping to the end of the file
not going through other parts of the code before.
Going back to the point where triple quotes comment begun (quite in the
middle of the file) and back to the end did the trick to get proper
highlighting again.
Apparently Vim syntax highlighting analyses only the code it has already
'seen' within the editing window. This is not what I expect from a
mature editor.
I have stopped here, because I found this problem after three seconds of
using it, so imagine how much other problems will become apparent after
using it three hours, right?
Vim similar as Wing has no [View] menu entry one can use for changing
the text appearance in any reasonable Windows program, so the ancient
Unix/Linux is still there with the system font as default setting for
displaying text... It looks as I were in a DOS box, not in a text editor
on Windows.
Loading a 100 MByte large file into this editor which pretends to be
able to edit files of any size results in an Error.
I was not able to find how to do rectangular select/paste and there was
no code folding for Python script code available.

Sorry, also this time still valid: Vim on Windows "no thank's".

I was just waste of my time to try it out again.

Claudio
 
G

gene tani

Claudio said:
Apparently Vim syntax highlighting analyses only the code it has already
'seen' within the editing window. This is not what I expect from a
mature editor.
I have stopped here, because I found this problem after three seconds of
using it, so imagine how much other problems will become apparent after
using it three hours, right?
Vim similar as Wing has no [View] menu entry one can use for changing
the text appearance in any reasonable Windows program, so the ancient
Unix/Linux is still there with the system font as default setting for
displaying text... It looks as I were in a DOS box, not in a text editor
on Windows.
Loading a 100 MByte large file into this editor which pretends to be
able to edit files of any size results in an Error.
I was not able to find how to do rectangular select/paste and there was
no code folding for Python script code available.

well, i'm not going to convince you but:

- Edit / Select font will let you choose font face / bold/italc and
size
- i have edited very large logfiles, CSVs etc in vim under linux and
FreeBSD, can't remember file sizes
- you probably do have to mess with .vimrc or get python.vim to get ti
the way you want, look here or searcht his newsgroup:

http://py.vaults.ca/~x/python_and_vim.html
http://www.redbrick.dcu.ie/~noel/vim.html
 
S

Sybren Stuvel

Claudio Grondi enlightened us with:
With [Strg]-[End] I went to the end of the file where I wanted to
continue editing, but the syntax highlighting told me there is no
code but only a comment. I checked it and found out, that Vim is
apparently not able to do proper highlighting when jumping to the
end of the file not going through other parts of the code before.

Vim does check parts of the buffer it hasn't displayed, but it only
goes back so much. Or would you rather have Vim check the entire
buffer every time you change it?
Going back to the point where triple quotes comment begun (quite in
the middle of the file) and back to the end did the trick to get
proper highlighting again.

Apparently you quoted so much that Vim didn't go all the way back to
check.
Apparently Vim syntax highlighting analyses only the code it has
already 'seen' within the editing window. This is not what I expect
from a mature editor.

Well, the problem is in your head, not with the editor. It uses sane
defaults to keep things fast. If you quote such a large amount of
text, wouldn't it be better to just store it in a text file? You could
also use the fact that Python joins consecutive string constants and
quote each paragraph:

"""Some text.
blablabla
"""
"""
Some more text blabla
"""

It'll result in some more quotes, but when running your program it's
the same, and VIM will be able to highlight it just fine.
I have stopped here, because I found this problem after three
seconds of using it, so imagine how much other problems will become
apparent after using it three hours, right?

Wrong. I have used Vim for years, and only found a few minor issues,
nothing more.
Vim similar as Wing has no [View] menu entry one can use for
changing the text appearance in any reasonable Windows program, so
the ancient Unix/Linux is still there with the system font as
default setting for displaying text... It looks as I were in a DOS
box, not in a text editor on Windows.

I can do "Edit -> Select font" just fine...
Loading a 100 MByte large file into this editor which pretends to be
able to edit files of any size results in an Error.

Never had problems with that.
I was not able to find how to do rectangular select/paste

Control+V to do block selects. After that, just paste.
and there was no code folding for Python script code available.

Yes there is - I'm using it.
It was just waste of my time to try it out again.

This is true for most things in life: If you go in with a negative
attitude and draw the wrong conclusions, you will only find what you
expected to find.

Sybren
 
C

Claudio Grondi

Sybren said:
Claudio Grondi enlightened us with:
With [Strg]-[End] I went to the end of the file where I wanted to
continue editing, but the syntax highlighting told me there is no
code but only a comment. I checked it and found out, that Vim is
apparently not able to do proper highlighting when jumping to the
end of the file not going through other parts of the code before.


Vim does check parts of the buffer it hasn't displayed, but it only
goes back so much. Or would you rather have Vim check the entire
buffer every time you change it?

Going back to the point where triple quotes comment begun (quite in
the middle of the file) and back to the end did the trick to get
proper highlighting again.


Apparently you quoted so much that Vim didn't go all the way back to
check.

Apparently Vim syntax highlighting analyses only the code it has
already 'seen' within the editing window. This is not what I expect
from a mature editor.


Well, the problem is in your head, not with the editor. It uses sane
defaults to keep things fast. If you quote such a large amount of
text, wouldn't it be better to just store it in a text file? You could
also use the fact that Python joins consecutive string constants and
quote each paragraph:

"""Some text.
blablabla
"""
"""
Some more text blabla
"""

It'll result in some more quotes, but when running your program it's
the same, and VIM will be able to highlight it just fine.
The file I was editing was just 22 KByte large having 450 lines, so you
try here to explain to me, that for speed reasons Vim has to cut it into
pieces? Stani SPE based on Scintilla does it right, UltraEdit does it
right, Wing does it right, so what, are we now on a 1 MHz computer with
128 KByte of memory for all the system and program files what would make
such approach necessary?
I want my file highlighted in a right way all the time and if it is too
large to be highlighted I want the editor to give a warning - yes, the
problem in my head is, that I don't accept bad and buggy software. I
have edited enough files with the line oriented vi to know what I am
speaking about.
Wrong. I have used Vim for years, and only found a few minor issues,
nothing more.
Let us know about them, so that we know it too.
Vim similar as Wing has no [View] menu entry one can use for
changing the text appearance in any reasonable Windows program, so
the ancient Unix/Linux is still there with the system font as
default setting for displaying text... It looks as I were in a DOS
box, not in a text editor on Windows.


I can do "Edit -> Select font" just fine...

Loading a 100 MByte large file into this editor which pretends to be
able to edit files of any size results in an Error.


Never had problems with that.
But this is what I have experienced. Are you on a *nix system?
I speak here about Microsoft Windows XP SP 2 on a 3GByte RAM equipped
Pentium 4 and Cream-Vim installed by
http://heanet.dl.sourceforge.net/sourceforge/cream/cream-0-33-1-gvim-6-3-90-1.exe
..
Control+V to do block selects. After that, just paste.


Yes there is - I'm using it.
But is does not work out of the box for me with the download I have
mentioned and I was not able to fix it as I tried.
This is true for most things in life: If you go in with a negative
attitude and draw the wrong conclusions, you will only find what you
expected to find.

Sybren
Yes, I see your point, but with the increasing speed of the hardware and
better software quality it is now possible to choose tools which are
easy to use and don't have a steep learning curve. Best, I don't need
any tutorial at all and can go with it directly. I am used to Microsoft
Windows way of designing user interfaces, so I expect software running
on Windows to provide what I am used to.
The times where the user had to adopt to the software are over. Now
there are all preconditions available making it possible to adopt the
software to the user.

What other editing tools have you already evaluated? I tried as many as
possible including Vim before I decided to spend money on purchasing
UltraEdit and inspite of the fact, that there are so many new editors
there, I still see no chance to replace UltraEdit with any other editing
tool and believe me, I would do it if it were possible, because I don't
like closed source solutions. I don't like the way the menues of
UltraEdit are designed and I have trouble to understand the text in the
help file, because it is not strightforward from my point of view; I
don't like, that one of the latest UltraEdit releases was buggy causing
100%CPU load and 2MByte of harddisk data traffic beeing idle, so I am
looking for an alternative for years, but instead of finding it I was
forced lately to spend money again on renewing my license.

No, I don't think, that it was my negative attitude what kicked Vim out
of beeing considered a mature editor for Python scripting purposes, at
least on a Windows system - it were the facts I have described and the
experience I had with other editing tools.

Just evaluate yourself at least SPE and Wing and come back to tell here
about your experience comparing them to Vim (do not forget to get rid of
the negative attitude first ;-).

Claudio
 
S

Sybren Stuvel

Claudio Grondi enlightened us with:
The file I was editing was just 22 KByte large having 450 lines, so
you try here to explain to me, that for speed reasons Vim has to cut
it into pieces?
Yep.

Stani SPE based on Scintilla does it right, UltraEdit does it right,
Wing does it right, so what, are we now on a 1 MHz computer with 128
KByte of memory for all the system and program files what would make
such approach necessary?

I'm giving you the reason why syntax highlighting in VIM doesn't
always do what you expect. I never said it wasn't a silly reason.
Having said that, A quick Ctrl+L usually fixes this for me.
Let us know about them, so that we know it too.

Syntax highlighting is awfully slow on files with very long lines.
That's the only thing I can think of now. And it's fixed in the
upcoming VIM 7.
But this is what I have experienced. Are you on a *nix system?
Yep.

I speak here about Microsoft Windows XP SP 2 on a 3GByte RAM
equipped Pentium 4 and Cream-Vim installed

I use Vim and GVim, on a 1.25 GB RAM equipped AthlonXP, on Ubuntu
Linux.
But is does not work out of the box for me with the download I have
mentioned and I was not able to fix it as I tried.

That's probably because when you install Vim in Windows, it changes
key settings to be more appropriate for Windows. Rip those
Win32-compatability crap out of your .vimrc (or is it called _vimrc
there?) so you can use all the keys everybody else can.
Yes, I see your point, but with the increasing speed of the hardware
and better software quality it is now possible to choose tools which
are easy to use and don't have a steep learning curve.

True. I find Vim very easy to use, and it didn't take me long to learn
it. It does help if you're on a platform which supplies 'vimtutor'
along with vim, and doesn't mangle the keybindings, though.
I am used to Microsoft Windows way of designing user interfaces, so
I expect software running on Windows to provide what I am used to.

LOL don't get me started on the Microsoft way in combination with my
expectations...
The times where the user had to adopt to the software are over.

You're very wrong there. Users have to adopt to the software, unless
they write their own. You also have to adopt to all sort of things in
your life, so what's the big issue with software?

To give you a few examples: I live in The Netherlands, so I buy cars
with the steering wheel on the left. I have to use that, no matter
what I want - unless I take the effort to import a car from abroad. I
have to screw to the right to get a screw inside a piece of wood. I
have to adopt to that. That's the way things work.
Now there are all preconditions available making it possible to
adopt the software to the user.

And most users get afraid of all those options they can set and all
those things they can tweak to get the software to adopt to their
whishes.
What other editing tools have you already evaluated? I tried as many
as possible including Vim before I decided to spend money on
purchasing UltraEdit and inspite of the fact, that there are so many
new editors there, I still see no chance to replace UltraEdit with
any other editing tool

I've tried UltraEdit, didn't like it, went back to Vim. Same with
other editors. I don't like the way I get popups in UE when I want to
search or replace something. I haven't tested this, but I haven't seen
a way to re-wrap text like Vim can - even in this post it can rewrap
your text without messing up the '>' symbols in front of it. It can
even rewrap comments, strings etc. in source code without messing up
indentation or marker characters.
Just evaluate yourself at least SPE and Wing and come back to tell
here about your experience comparing them to Vim

I'll see if I can get around to it. I'm very busy atm, but I'm busy
doing Python programming, so perhaps I can do some with the IDEs you
mentioned.

Hmm... neither are bundled with Ubuntu.

SPE is already annoying because of all the new windows it opens... Not
a good start. I remember using it before, to check out the Blender
integration. Unfortunately, that didn't work. I'll give it another go.

WingIDE is commercial software, which I'm not going to use. I'm not
all against commercial software, but if there is a Free alternative,
I'd rather use that.

Sybren
 
S

Sybren Stuvel

Sybren Stuvel enlightened us with:
SPE is already annoying because of all the new windows it opens...
Not a good start. I remember using it before, to check out the
Blender integration. Unfortunately, that didn't work. I'll give it
another go.

I downloaded it, tried to run it, then it stopped with a message that
it needs a newer wxPython version than the one that comes with Ubuntu
Linux. Since this release of Ubuntu is two months old and rather up to
date with all things Python, IMO the SPE builders are pushing it a
little too much by requiring even a newer version of wxPython.

Sybren
 
B

bonono

I have been using vi/vim for a very long time and love it(now using
ion3 + vim, not even gvim on debian), but never found it blend well
with the Windows GUI.
 
B

BartlebyScrivener

If you're on Windows XP why not try Xemacs? That's free and does syntax
highlighting etc. Doesn't have a problem with large files and so on.

rpd
 
C

Claudio Grondi

BartlebyScrivener said:
If you're on Windows XP why not try Xemacs? That's free and does syntax
highlighting etc. Doesn't have a problem with large files and so on.

rpd
Installed:
http://ftp.dk.xemacs.org/pub/emacs/xemacs/binaries/win32/InnoSetup/XEmacs Setup 21.4.18-1.exe

Requesting help file I have got a plain text window with following text:

Copyright (c) 1985, 1996 Free Software Foundation, Inc. See end for
conditions.

You are looking at the Emacs tutorial.

Emacs commands generally involve the CONTROL key (sometimes labelled
CTRL or CTL) or the META key. On some keyboards, the META key is
labelled ALT or EDIT or something else (for example, on Sun keyboards,
the diamond key to the left of the spacebar is META). If you have no
META key, you can use ESC instead. Rather than write out META or
CONTROL each time we want you to prefix a character, we'll use the
following abbreviations:

C-<chr> means hold the CONTROL key while typing the character <chr>
Thus, C-f would be: hold the CONTROL key and type f.
M-<chr> means hold the META key down while typing <chr>. If there
is no META key, type <ESC>, release it, then type the
character <chr>.

Important note: to end the Emacs session, type C-x C-c. (Two characters.)
The characters ">>" at the left margin indicate directions for you to
try using a command.

....

Out of the box after installation of
http://ftp.dk.xemacs.org/pub/emacs/xemacs/binaries/win32/InnoSetup/XEmacs Setup 21.4.18-1.exe
gives me an editor window, but
- no syntax highlighting for edited Python file (no idea how to get it)
- no line numbering (a menu item is there, but clicking on it doesn't
change anything)
- no ruler (a menu item is there, but clicking has no effect)
- [CTRL]+MouseSelection results in some editing action I don't
understand ...

I know emacx from the ancient time of computer technology, but I have
never made to learn how to control it.
By the way: I was a keyboard fan years ago, but now I would be glad to
have some basic typing capability on my mouse, because most of the time
I am moving the mouse, not typing much text on a keyboard even editing
scripts.

Claudio
 
B

BartlebyScrivener

Go to Options. Near the bottom, it will say "Edit Init.File" Click on
it.

Make an entry on a separate line near the top as follows

(require 'python-mode)

Then save the init file.

When you open files with a .py extension xemacs should automatically go
into "python mode"

If you read the init.el file it will teach you a little about how to
configure it. If you don't care about that and only want a python
editor, then just add the line above.

rpd
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top