Re: [Python-mode] trying to upgrade

2012-04-08 Thread Glenn Linderman

On 4/7/2012 11:41 PM, Andreas Röhler wrote:

Am 08.04.2012 01:54, schrieb Glenn Linderman:

Hi Andreas, et alia,

Slowly the wheels turn, and progress is made. And then there are 
bumps in the road. This is probably a bump.




You might recall that I was stuck on an old version of emacs because 
of incompatibilities newer versions had with AutoHotKey. It was more 
important for me to be compatible,
than to run the latest emacs. Then recently I discovered the beta 
emacs is now compatible with AutoHotKey again, at least, as much as 
the old version was (there are still

some issues, but they are not new).

So references here are to this emacs:

GNU Emacs 24.0.93.1 (i386-mingw-nt6.1.7601)
of 2012-02-15 on MARVIN

So I upgraded to the above new emacs, and now am upgrading to the new 
python-mode.el. I was running python-mode.el 6.0.2 and I see 6.0.5 is 
now the latest version, so I
downloaded it, tweaked my load-path to point to the new one, and 
opened a quite valid, successfully executing Python 3 source file.


The following error appeared in the minibar:

Error in menu-bar-update-hook (imenu-update-menubar): (error Lisp 
nesting exceeds `max-lisp-eval-depth')


Hi Glenn

might be related to some indexing issue.

customize py-imenu-create-index-p to nil should avoid this anyway.

I'm testing with Emacs24 too from time to time and it passed as 
Emacs23 so far.


Nonetheless Emacs24 got some major changes and has some issues still.
Unless actively developing it, recommend Emacs23 for all productive work.

As for the rest, let's try to solve the knot by doing it one by one.

- disable all optional features as outline-mode - customize 
py-outline-minor-mode-p nil



If you still encounter some issues with latest release, please send an 
example file which triggers it, resp. make a bug report.


Best regards,

Andreas


Your suggestions sound good.  Since they didn't look like elisp syntax, 
I tried the menus, Options / Customize Emacs / Programming / Languages / 
Python ... but couldn't guess where to go next.


So I apologize, I am unable to intuit elisp syntax from the above prose, 
nor guess my way into the customize tree to find them.  Can you be more 
explicit on what to do to turn of the options that might bypass these 
symptoms?  I don't grok much of the elisp parenthesis soup, I'm just an 
emacs user with a bit of .emacsrc cut-n-paste ability.


As for emacs 24, I am no emacs developer, but I cannot use emacs 22 or 
23 due to incompatibilities with AutoHotKey, and 21 works fine for me 
for normal things, but is maybe too old for the latest python-mode, 
since you were not able to reproduce problems I had in the past.  So it 
is 21 or 24, which, if either, can you support with python-mode? Maybe 
it is premature to use 24, but I am supposing, unless you declare 
otherwise, that it is much more interesting to add support for 24 into 
python-mode than to support 21...
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode


[Python-mode] trying to upgrade

2012-04-07 Thread Glenn Linderman

Hi Andreas, et alia,

Slowly the wheels turn, and progress is made.  And then there are bumps 
in the road.  This is probably a bump.


You might recall that I was stuck on an old version of emacs because of 
incompatibilities newer versions had with AutoHotKey.  It was more 
important for me to be compatible, than to run the latest emacs.  Then 
recently I discovered the beta emacs is now compatible with AutoHotKey 
again, at least, as much as the old version was (there are still some 
issues, but they are not new).


So references here are to this emacs:

GNU Emacs 24.0.93.1 (i386-mingw-nt6.1.7601)
 of 2012-02-15 on MARVIN

So I upgraded to the above new emacs, and now am upgrading to the new 
python-mode.el.  I was running python-mode.el 6.0.2 and I see 6.0.5 is 
now the latest version, so I downloaded it, tweaked my load-path to 
point to the new one, and opened a quite valid, successfully executing 
Python 3 source file.


The following error appeared in the minibar:

Error in menu-bar-update-hook (imenu-update-menubar): (error Lisp 
nesting exceeds `max-lisp-eval-depth')


5 Py* menu entries appeared in the menu, however, so some menu updates 
apparently did work.


I note that loading python-mode.el takes a _long_ time (noticeable 
delay), probably do to this eval-depth limit being reached.


I notice that instead of my major mode being Python it is now Python 
Outl and I don't know why that should be (but I probably missed 
understanding something, in the emails about the new versions)?


I was inspired to do this, because python-mode.el 6.0.2 with this same 
version of emacs, entered an infinite loop when loading a .py file that 
had major syntax errors (it was actually just some text that I had 
planned to convert into a python program that would incorporate the 
techniques described by the text).  Happily this doesn't happen with the 
new python-mode.el 6.0.5, but that file also winds up in Python Outl mode.


Advice, please.  Is this an issues with emacs 24? a bug in python-mode 
6.0.5? something triggered by the particular python file? Or something else?


Glenn
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode


Re: [Python-mode] script with indentation problems - Bug 818669

2011-08-10 Thread Glenn Linderman

On 8/10/2011 1:11 AM, Andreas Röhler wrote:

restored the good old cycling behavior.
New design remains available as py-indent-line-new. 


I'm not sure what cycling behavior means?  Is that documented somewhere?

What I would expect, is that if point arrives at a line, and the text 
starts somewhere other than the appropriate default position on the 
line, and point is before the text starts, that the first TAB would move 
the text to the appropriate default position on the line.


Subsequent TAB should move the text one indent to the right.

What I was seeing was that the second TAB would move text two indents to 
the right.  Or sometimes the second TAB would do nothing, and then the 
third TAB would move text two indents to the right.  Is there ever a 
situation where a TAB should move text more than one indent to the right?


I'll grab your latest branch after some sleep and test again... thanks!
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode


Re: [Python-mode] script with indentation problems - Bug 818669

2011-08-09 Thread Glenn Linderman

On 8/8/2011 10:59 PM, Andreas Röhler wrote:

Hi,




3) Line 1266 (authlist = None). Point in column 1. Hit TAB.



... Hit TAB again, and it gets indented 8 spaces
instead 4.


at my machine it stays at current-indentation with TAB, which is
a new behavior


Are you saying you are testing with a newer version than this 
morning's?  I still see this behavior except that it sometimes 
happens with the second TAB, and sometimes with the third.


What I don't understand is why TAB would ever move text more than one 
indent at a time (8 character positions instead of 4).
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode


Re: [Python-mode] python-mode.el 6.0 released

2011-07-24 Thread Glenn Linderman

On 7/23/2011 11:34 PM, Andreas Röhler wrote:



Please write a bug report. Also posting on the emacs-help might be
useful.


Thanks for your suggestions here, I know it is out of scope for
python-mode. But reporting the bug in emacs 3 years ago, and the
deficiencies of that process from a user perspective, do not encourage
following the process again...


Please take in consideration the tremendous work the Emacs 
core-developers are delivering. Have a look at what you get from it 
and ask where it's coming from. From my perspective these people 
deserve our assistance and patience likewise.


Sure, it's a great program.  I've been using it for at least 20 years!  
Unicode didn't exist back then.  This is the first time they've 
delivered a new feature that doesn't work... sadly.  But I can 
understand that converting a program that didn't use Unicode, to use 
Unicode, is a huge effort.  On the other hand, there are lots of bug 
trackers floating around, and the process I found in the documentation 
is severely brain-damaged on Windows but... reading on





I was hoping there might be some other

interface to the process that I overlooked, or which augments the
process whose documentation I was able to find, and, with great effort,
follow.

So, I did write a bug report email for this exact issue, for emacs 23.1,
3 years ago. But I have no way to check its status.



http://debbugs.gnu.org/


This looks promising :)  I don't need to learn why I didn't find it from 
reading the docs, I guess.  On the other hand, maybe it is new, since I 
last looked.  Seems it is still all email based, and no obvious way to 
add status to the bug via this interface... maybe via email?  Anyway, 
the problem with not opening files containing particular characters in 
their names is reported, and open, so perhaps someday that will get fixed.


The problem with packet is invalid I cannot find record of in the 
bug tracker, but ...





 Is there a different

interface? The bug report email stuff doesn't work very well on Windows,
I had to generate it to a file, and then send the file (or something
weird, it has been 3 years since I reported it first, and I've maybe
forgotten the details). Where is the best way to send the bug report?
That way didn't seem to produce much response, and certainly not a
response that I can monitor for status in any way and the problem
still exists 3 years later. Pretty sad.

What is the emacs-help and how does one post on it? Is that a
newsgroup, an emacs feature, or a web site, or something else?


http://lists.gnu.org/archive/html/help-gnu-emacs/


It is findable here, as thread:
http://lists.gnu.org/archive/html/help-gnu-emacs/2009-08/msg00720.html



Andreas


Anyway, thanks for you help locating the bug tracker, such as it is.  
Happily, I don't actually edit huge numbers of files containing accented 
characters in their names or contents, at least, not the ones that emacs 
doesn't properly handle.   But it is surely painful when I do... and 
even more painful when I try to do it with emacs 23.x.
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode


Re: [Python-mode] python-mode.el 6.0 released

2011-07-23 Thread Glenn Linderman

On 7/23/2011 9:48 AM, Andreas Röhler wrote:

Hi all,

proudly announcing the release of

python-mode.el 6.0 at

http://launchpad.net/python-mode/trunk/6.0/+download/python-mode-6.0.tgz


Installation instructions?

Seems like the prior python-mode was just a single file, so pretty 
straightforward, unpack to d:\somewhere, and then in the emacs rc:


(add-to-list 'load-path d:/somewhere)
(autoload 'python-mode python-mode Python Mode. t)


The new one has lots of files, not sure what to do with them... anyway, 
did the same as above, and get the following error:


Error in menu-bar-update-hook: (void-function region-active-p)


Gnu Emacs 22.1.1 here.  I'd upgrade to a newer Emacs, but last time I 
tried, the better Unicode support was actually worse.  (Trying to open 
files with Unicode names, and trying to paste in Unicode text from 
AutoHotKey.)
___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode


Re: [Python-mode] python-mode.el 6.0 released

2011-07-23 Thread Glenn Linderman

On 7/23/2011 1:23 PM, Andreas Röhler wrote:




Seems like the prior python-mode was just a single file, so pretty
straightforward, unpack to d:\somewhere, and then in the emacs rc:

(add-to-list 'load-path d:/somewhere)
(autoload 'python-mode python-mode Python Mode. t)


make sure python-mode.el is earlier in path than python.el






Does add-to-list do that?


Good question. M-x describe-variable RET load-path should tell you.

As for the issues with python.el think the simplest solution in 
question is to load it directly.


(load MYPATH/python-mode.el)


 Or do I need something else?




python-mode.el should not need anything else.



Thanks.  Seems add-to-list puts it in the front.  Guess there is no harm 
in having the rest sit there unused...




[ ... ]


Doesn't meet my experience. We are on Emacs23.3 which is the best
Emacs ever IMHO.


Glad it is working for you, but it isn't for me. I offer the following
description of the problem, but of course it is not a problem with
python-mode. But it will serve to explain why my attempts to use 23.1
some time back and 23.3 today, have failed.

None of Emacs 22.1.1 through 23.3 will open files on Windows containing
certain characters in their names, partly because the name can't be
typed properly, but it doesn't even work to drag files with those names
into emacs. Probably an issue that is specific to Windows. Those same
characters produce some weird error packet is undefined when certain
characters are pasted into Emacs by Autohotkey, using at least
23.1-23.3. 22.1.1 doesn't produce the packet error, so is friendlier
to those characters. Probably another issue that is unique to Windows
and/or AutoHotKey interaction. I've tried reporting the packet error,
and eventually someone responded to the email, but I never figured out a
way to check on the status of a ticket, or figure out when or if it will
be included in a production version of emacs. As I use AutoHotKey macros
to generate non-ASCII symbols using an English keyboard, it is critical
to my ability to use Unicode characters, and not being able to enter
them using emacs makes such versions of emacs useless to me. I have
never learned Emacs lisp, which is usually not a major problem in simply
using Emacs, and I can copy/paste helpful tricks from various web
sites for customization. But this is beyond my capabilities to analyze,
so I may be stuck on emacs 22.1.1 until someone can fix the problem or
until I have to give up emacs because 22.1.1 no longer works on some
future version of Windows.



Please write a bug report. Also posting on the emacs-help might be 
useful.


Thanks for your suggestions here, I know it is out of scope for 
python-mode.  But reporting the bug in emacs 3 years ago, and the 
deficiencies of that process from a user perspective, do not encourage 
following the process again... I was hoping there might be some other 
interface to the process that I overlooked, or which augments the 
process whose documentation I was able to find, and, with great effort, 
follow.


So, I did write a bug report email for this exact issue, for emacs 23.1, 
3 years ago.  But I have no way to check its status.  Is there a 
different interface?  The bug report email stuff doesn't work very well 
on Windows, I had to generate it to a file, and then send the file (or 
something weird, it has been 3 years since I reported it first, and I've 
maybe forgotten the details).  Where is the best way to send the bug 
report?  That way didn't seem to produce much response, and certainly 
not a response that I can monitor for status in any way and the 
problem still exists 3 years later.  Pretty sad.


What is the emacs-help and how does one post on it?  Is that a 
newsgroup, an emacs feature, or a web site, or something else?


I did spend some time today upgrading my AutoHotKey to the latest 
version, but it produces the same effect in emacs 23.3 as the 3-year-old 
version I was using had produced in emacs 23.1 when I tested it... 
packet is undefined.  But that packet seems to work for every 
other program I use the AutoHotKey features with... so it (still) seems 
more likely to be an Emacs issue than an AutoHotKey issue.



Andreas


___
Python-mode mailing list
Python-mode@python.org
http://mail.python.org/mailman/listinfo/python-mode