Re: python.el update

[Dave Love]

Stefan Monnier <address@hidden> writes:

> -- I see you added a python-comment-indent that aligns the comment to the
>    one on the previous line.  It looks a bit simplistic: it never uses
>    comment-column and it will align strangely as follows:
>
>     foo # some comment
>
>         # here is a new strangely aligned comment.

In what circumstances?  It could be changed to check for preceding
blank lines, but I don't think you normally get in that situation.
When I was using it, the code seemed to DTRT, but without grovelling
newcomment again, I'm not clear what the hook function is supposed to
do and in quite what circumstances it gets called.  Perhaps the doc
for it could be made more explicit?

>    Furthermore, the default code should already DTRT since it delegates the
>    work to indent-according-to-mode.  So could you explain why you need
>    a specific function?  Maybe we can fix the generic code instead.

To avoid ending up with something like this on C-M-j:

def ...
    ...

# ...
    # ...

Auto-indentation simply can't always DTRT with the offside rule (not
that Python's layout is proper offside, like Haskell).

> -- python-comment-line-p seems wrong: it returns nil on a blank line
>    contrary to what the doc says.

The doc's wrong.

> -- I've changed the
>
>    (define-key map (car (where-is-internal 'complete-symbol (list 
> global-map)))
>      'python-complete-symbol)

Ta.  Silly me.

> -- I've moved the define-keys for inferior-python-mode to a defvar.

The doc string for define-derived-mode doesn't mention keymap
inheritance, and I think it should.  I didn't know it did that (though
it is actually in the Lisp manual).

> -- What's the point of
>
>    (define-key inferior-python-mode-map "\C-c\C-z" 'python-switch-to-python)

I guess it's a cut/paste-o, ta.

> -- Any hope to see the emacs.py file included in the python
> distribution?

No, but you wouldn't want it to be.  It's specific to the Emacs mode.
There isn't actually anything wrong with including files with bits of
other languages like that, is there?

> -- I've replaced
>
>        (with-output-to-temp-buffer "*Help*"
>    with
>        (help-setup-xref (list 'python-describe-symbol symbol))
>        (with-output-to-temp-buffer (help-buffer)
>
>    so that a [back] button could work 

That's not relevant currently since you can't link into or out of it,
so I disabled it to avoid a broken [back].

> -- Regarding your comment before python-complete-symbol saying we should
>    have something like that in the core, I agree and we basically already
>    have it: minibuffer-complete.

I don't understand.  Could you be more explicit?

I thought minibuffer-complete was basically an internal function.  I
envisaged something that provided the boilerplate and took a function
to select the partial symbol and one to produce a completions list
from it.  I guess if minibuffer-complete can use local variables
pointing to functions to do that, it's fine, but `local' in that case
means the minibuffer, doesn't it?