Re: Python mode and eldoc "freeze"

2006-10-31 Thread Slawomir Nowaczyk 
On Tue, 31 Oct 2006 15:22:09 -0500
John Sullivan <[EMAIL PROTECTED]> wrote:

#> I mean built-in functions, like
#> http://docs.python.org/lib/built-in-funcs.html.
#> 
#> Running down that list now, some of them work and some of them don't.
#> 
#> For example, pow() and ord() work. open() and property() and
#> reversed() do not. I gather this is because the latter are classes in
#> __builtin__, and so their doc strings look different.

OK, thanks... I have only checked a couple I remembered by heart and
they were all "normal" functions, so they worked. In fact, things like
open() and property() are "types", not functions. I am not *entirely*
sure we want to display eldoc messages for types in general, but I do
not see anything terribly wrong with that...

The patch below makes all of built-ins listed on the page you mention to
echo eldoc messages for me (except for "help" which actually evaluates
to *string*).

**

--- /EmacsCVS/etc/emacs.py   2006-10-26 23:25:56.225217600 +0200
+++ /Emacs/etc/emacs.py   2006-11-01 00:13:29.307024000 +0100
@@ -50,12 +50,11 @@
if len (parts) > 1:
exec 'import ' + parts[0] # might fail
func = eval (name)
-   if inspect.isbuiltin (func):
+   if inspect.isbuiltin (func) or type(func) is type:
doc = func.__doc__
if doc.find (' ->') != -1:
print '_emacs_out', doc.split (' ->')[0]
-   elif doc.find ('\n') != -1:
-   print '_emacs_out', doc.split ('\n')[0]
+print '_emacs_out', doc.split ('\n')[0]
return
if inspect.ismethod (func):
func = func.im_func

**

Here is changelog entry:

2006-11-01  Slawomir Nowaczyk  <[EMAIL PROTECTED]>

* emacs.py: (eargs) Provide eldoc message for builtin types.
  Make sure eargs always outputs sentinel, to avoid emacs freeze.

**

#>> What would you like to see displayed for things like import or
#>> except? The output of "help('import')" is pretty long... First
#>> sentence might make some sense, but I am not sure if it would be
#>> useful?

#> The Python Pocket Reference gives an abbreviated version of the
#> grammar (from the beginning of the docstrings) for import.

By "Python Pocket Reference", do you mean the book? I think it would be
better to get the text from actual Python interpreter installed on user
machine, just in case there is a version mismatch.

#> Even that's a little long, so maybe just "import module [,
#> module]*..." would be good.

Maybe... where should this info come from? The output of help("import")
starts with:

  6.12 The import statement
  
import_stmt  ::= "import" module[1] ["as" name[2]] ( "," 
module[3] ["as" name[4]] )*
| "from" module[5] "import" identifier[6] ["as" name[7]]
  ( "," identifier[8] ["as" name[9]] )*
| "from" module[10] "import" "(" identifier[11] ["as" 
name[12]]
  ( "," identifier[13] ["as" name[14]] )* [","] ")"
| "from" module[15] "import" "*"
module   ::= (identifier[16] ".")* identifier[17]

I do not think any (part) of this is suitable for eldoc.

Or do you suggest we actually write some hardcoded eldoc messages? Do we
do it for current version only or should we cater for older versions as
well (like 2.2 where "yield" was not a keyword)?

-- 
 Best wishes,
   Slawomir Nowaczyk
 ( [EMAIL PROTECTED] )

If at first you don't succeed, skydiving is not for you.



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Python mode and eldoc "freeze"

2006-10-31 Thread John Sullivan 
Slawomir Nowaczyk <[EMAIL PROTECTED]> writes:

> Current code works fine for me with __builtins__... or did you mean
> "keywords"?
>

I mean built-in functions, like
http://docs.python.org/lib/built-in-funcs.html.

Running down that list now, some of them work and some of them don't.

For example, pow() and ord() work. open() and property() and reversed() do not.
I gather this is because the latter are classes in __builtin__, and so their
doc strings look different.

[...]

> On my machine, nothing is echoed for keywords. I don't use eldoc
> normally, though, so I do not know if it always used to work like this.
>
> What would you like to see displayed for things like import or except?
> The output of "help('import')" is pretty long... First sentence might
> make some sense, but I am not sure if it would be useful?
>

The Python Pocket Reference gives an abbreviated version of the grammar (from
the beginning of the docstrings) for import. Even that's a little long, so
maybe just "import module [, module]*..." would be good.

Unfortunately help("except") shows the documentation for try. Not sure what to
do about that one.

-- 
-John Sullivan
-http://www.wjsullivan.net
-GPG Key: AE8600B6



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Python mode and eldoc "freeze"

2006-10-27 Thread Richard Stallman 
> After some trial and error, I propose the following patch.  I have
> verified that it makes the reported bug go away.  Does anyone disagree
> with it?

Yes, though I'm not interested in that fork.

We cannot switch to a different version now, before the release.
We need to fix the current code in local, safe ways.
Would you please help?

After the release, we could switch to your version if you help us
do that.


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Python mode and eldoc "freeze"

2006-10-27 Thread Slawomir Nowaczyk 
On Mon, 23 Oct 2006 02:46:43 -0400
John Sullivan <[EMAIL PROTECTED]> wrote:

#> Chong Yidong <[EMAIL PROTECTED]> writes:
#> 
#> > After some trial and error, I propose the following patch.  I have
#> > verified that it makes the reported bug go away.  Does anyone disagree
#> > with it?
#> 
#> Thanks, I tested this patch, and it solved the "freeze". But I
#> noticed that when point was over any of the builtins, the only thing
#> echoed was "()".

Current code works fine for me with __builtins__... or did you mean
"keywords"?

#> I don't have time to check at the moment whether this is a regression
#> -- ISTR that docs for things like "import" and "except" were echoed,
#> but maybe I'm misremembering.

On my machine, nothing is echoed for keywords. I don't use eldoc
normally, though, so I do not know if it always used to work like this.

What would you like to see displayed for things like import or except?
The output of "help('import')" is pretty long... First sentence might
make some sense, but I am not sure if it would be useful?

-- 
 Best wishes,
   Slawomir Nowaczyk
 ( [EMAIL PROTECTED] )

Take my advice, I don't use it anyway.



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Python mode and eldoc "freeze"

2006-10-26 Thread Stefan Monnier 
> Yes, though I'm not interested in that fork.

Why do you consider it as a fork?  AFAICT it's your code.
  
> I advise people who want a Python mode to use what I maintain for
> Emacs 21 (notwithstanding various wrinkles).  Its eldoc support works.
> I gave up trying to keep the original version running against the
> breakage in the development Emacs, but it worked with eldoc when I
> last had it running.

Why don't you submit your changes?  Again, AFAIK you're the author of that
code, you submitted it for inclusion, and since you maintain that mode
(outside Emacs), why would you not want to maintain that code inside Emacs
as well.


Stefan


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Python mode and eldoc "freeze"

2006-10-26 Thread Dave Love 
Chong Yidong <[EMAIL PROTECTED]> writes:

> After some trial and error, I propose the following patch.  I have
> verified that it makes the reported bug go away.  Does anyone disagree
> with it?

Yes, though I'm not interested in that fork.  If I recall correctly
the eldoc support in it was long broken, but was supposed to be fixed
a while ago; you could look for the source of the recent regression.

Such a change shouldn't be necessary and the function shouldn't fail
just because execing imports stuff raises an exception.

  (python-send-receive "")
=> nil
  (python-send-receive "emacs.eargs('len','import')")
=> "len(object)"
  
I advise people who want a Python mode to use what I maintain for
Emacs 21 (notwithstanding various wrinkles).  Its eldoc support works.
I gave up trying to keep the original version running against the
breakage in the development Emacs, but it worked with eldoc when I
last had it running.


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Python mode and eldoc "freeze"

2006-10-24 Thread John Sullivan 
Chong Yidong <[EMAIL PROTECTED]> writes:

> After some trial and error, I propose the following patch.  I have
> verified that it makes the reported bug go away.  Does anyone disagree
> with it?

Thanks, I tested this patch, and it solved the "freeze". But I noticed that
when point was over any of the builtins, the only thing echoed was "()". I
don't have time to check at the moment whether this is a regression -- ISTR
that docs for things like "import" and "except" were echoed, but maybe I'm
misremembering. Docs are correctly echoed for anything that is imported (like
urllib2.urlopen).

-- 
-John Sullivan
-http://www.wjsullivan.net
-GPG Key: AE8600B6



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Python mode and eldoc "freeze"

2006-10-22 Thread Stefan Monnier 
> After some trial and error, I propose the following patch.  I have
> verified that it makes the reported bug go away.  Does anyone disagree
> with it?

Looks good to me,


Stefan "who's never actually used Python"


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Python mode and eldoc "freeze"

2006-10-20 Thread Chong Yidong 
Chong Yidong <[EMAIL PROTECTED]> writes:

> Basically, python-send-receive (called by python-eldoc-function) is
> waiting forever for input to arrive.  It expects to receive a string
> "_emacs_out" from the emacs.eargs Python function (defined in
> etc/emacs.py) in the inferior python process.
>
> Apparently if the exec fails, this function neglects to print
> '_emacs_out'.  This can be verified using
>
> I don't know enough Python to fix this.  Can someone help?

After some trial and error, I propose the following patch.  I have
verified that it makes the reported bug go away.  Does anyone disagree
with it?

*** emacs/etc/emacs.py.~1.8.~   2006-08-21 00:19:17.0 -0400
--- emacs/etc/emacs.py  2006-10-21 00:55:36.0 -0400
***
*** 59,71 
return
if inspect.ismethod (func):
func = func.im_func
!   if not inspect.isfunction (func): return
(args, varargs, varkw, defaults) = inspect.getargspec (func)
# No space between name and arglist for consistency with builtins.
print '_emacs_out', \
func.__name__ + inspect.formatargspec (args, varargs, varkw,
   defaults)
! except: pass
  
  def all_names (object):
  """Return (an approximation to) a list of all possible attribute
--- 59,74 
return
if inspect.ismethod (func):
func = func.im_func
!   if not inspect.isfunction (func):
! print '_emacs_out ()'
! return
(args, varargs, varkw, defaults) = inspect.getargspec (func)
# No space between name and arglist for consistency with builtins.
print '_emacs_out', \
func.__name__ + inspect.formatargspec (args, varargs, varkw,
   defaults)
! except:
!   print "_emacs_out ()"
  
  def all_names (object):
  """Return (an approximation to) a list of all possible attribute


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Python mode and eldoc "freeze"

2006-10-20 Thread Chong Yidong 
johnsu01 <[EMAIL PROTECTED]> writes:

> I'm using the python-mode included with this version of emacs.
>
> I have (add-hook 'python-mode-hook 'turn-on-eldoc-mode).
>
> When I move to any keyword in a python source file, expecting information to 
> be
> shown in the minibuffer, emacs appears to freeze. I can't move point or type
> anything.
>
> When I hit C-g, then the effects of all the typing I did during the "freeze"
> appear. So if I hit C-u C-n while frozen, after C-g, point moves down 4 lines.

Basically, python-send-receive (called by python-eldoc-function) is
waiting forever for input to arrive.  It expects to receive a string
"_emacs_out" from the emacs.eargs Python function (defined in
etc/emacs.py) in the inferior python process.  The trouble is in
emacs.eargs:

def eargs (name, imports):
"Get arglist of NAME for Eldoc &c."
print 'goo'
try:
if imports: exec imports
parts = name.split ('.')
if len (parts) > 1:
exec 'import ' + parts[0] # might fail


Apparently if the exec fails, this function neglects to print
'_emacs_out'.  This can be verified using

  M-x run-python RET  
  emacs.eargs("self.foo", "import binascii\n")
  RET

I don't know enough Python to fix this.  Can someone help?


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Python mode and eldoc "freeze"

2006-10-20 Thread johnsu01 
I'm using the python-mode included with this version of emacs.

I have (add-hook 'python-mode-hook 'turn-on-eldoc-mode).

When I move to any keyword in a python source file, expecting information to be
shown in the minibuffer, emacs appears to freeze. I can't move point or type
anything.

When I hit C-g, then the effects of all the typing I did during the "freeze"
appear. So if I hit C-u C-n while frozen, after C-g, point moves down 4 lines.

I tried toggle-debug-on-quit, but I didn't get a backtrace when I hit C-g.

In GNU Emacs 22.0.50.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2006-10-09 on pacem, modified by Debian
 (Debian emacs-snapshot package, version 1:20061009-1)
configured using `configure '--build' 'i486-linux-gnu' '--host' 
'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' 
'--libexecdir=/usr/lib' '--localstatedir=/var' '--infodir=/usr/share/info' 
'--mandir=/usr/share/man' '--with-pop=yes' 
'--enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/22.0.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/22.0.50/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/22.0.50/leim'
 '--with-x=yes' '--with-x-toolkit=athena' '--with-toolkit-scroll-bars' 
'CFLAGS=-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2' 
'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: Summary

Minor modes in effect:
  shell-dirtrack-mode: t
  erc-list-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-netsplit-mode: t
  erc-match-mode: t
  erc-stamp-mode: t
  erc-truncate-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-readonly-mode: t
  iswitchb-mode: t
  show-paren-mode: t
  encoded-kbd-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t

Recent input:
v ESC v ESC < c y C-n C-n C-n C-n C-n C-n C-p RET c 
y RET C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n RET SPC n SPC 
n SPC n SPC c y C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-p C-p C-p C-p C-p C-p C-p C-p C-p RET RET C-s p y 
t h o n C-s C-n ESC > ESC x r e p o r t SPC e m a c 
s SPC b u g RET

Recent messages:
Processing kill file /home/johnsu01/News/KILL...done
Invalid face reference: myblack [94 times]
Auto-saving...
Invalid face reference: myblack [712 times]
Mark saved where search started
Invalid face reference: myblack [97 times]
Mark set
Invalid face reference: myblack [132 times]
Loading emacsbug...done
Invalid face reference: myblack [44 times]


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug