Bonsoir,
On Sat, Apr 9, 2011 at 4:25 PM, anatoly techtonik <[email protected]> wrote:
> Is the command prompt a part of current buffer (for code highlighting)
> or not? I.e. do previous lines participate in rendering line in
> command prompt?
I'm not sure I really understand that part. All lines in the current
block ("current block" being all the lines up to when the prompt turns
from "... " back to ">>> " again) take part in highlighting, yes
(needed for example when highlighting multiline strings: previous
lines influence how the current line is being highlighted). Most of
the hard work in respect to highlighting is done by Pygments. We also
use it for tokenising Python code.
>> The basic idea of porting new UIs to bpython is to inherit from
>> "bpython.repl.Repl" and implement some methods (like "current_line"
>> that returns the current input line, setting the "cpos" attribute that
>> indicates where the cursor is positioned etc.).
>
> Got it. Seems pretty low level architecture.
Yes. It was sufficient so far and nobody came up with some better design yet.
>> That process is not
>> really documented, please feel free to document it.
>
> Who are the right people to annoy with merge requests?
>
> bobf
> federico
> ikanobori
> marienz
> Trundle
bobf and I (Trundle) are the official maintainers, but a lot of the
work is done by ikanobori. For documentation changes, you should bug
ikanobori.
> But while previous lines can't change, their visual representation can
> - is that right?
That is correct, yes.
> Sorry if it sounds too abstract. Let me explain why adding new UI to
> bpython is hard. To add new UI you expect to study how the basic
> loop/cycle works using minimal example. My case is even worse, because
> even full example doesn't work failing with with "No module named:
> _curses" on Windows. To find an entrypoint for further analysis I need
> to study how curses works, or how GTK works or how urwid+twisted work
> together. All in theory, because neither UI works on this machine. But
> there are some things that could help.
I really recommend looking at urwid and gtk instead of curses, it's a
bit less low-level. The usual assumption that worked well so far is
that you know how handling input and outputting stuff works in the UI
toolkit of your choice works and then you try to teach bpython about
it. Also, virtual machines are easy to set up nowadays.
> For making any changes, it is good to know application components.
> While there could be separate docs, code is the best documentation,
> unless it is a dead code. The best way to see if the code is alive is
> to execute it and follow through the entrypoint. When I executed
> bpython, I assumed it is a big application and expected it to do
> several things prior to initialization of UI (yes, I am a naive
> idealist). Namely detecting available frontends and choosing the
> default one. But this doesn't work - you have to explicitly run script
> for your UI. More than that - to find these entrypoints - you need to
> look through all files in bpython package (urwid interface doesn't
> have a command line script, for example).
> However, these scripts don't
> work from checkout without setting PYTHONPATH properly. For fix this
> problem I've patched data/* scripts to execute bpython directly from
> checkout, so you may pull these changes from
> https://bitbucket.org/techtonik/bpython
Please don't try to mess around with sys.path. FWIW, I will never pull
any change that does something like that. If you want to run bpython
from a checkout, either set PYTHONPATH or use "python -m bpython.cli"
(replace "cli" with "gtk_" or "urwid" if you want another UI).
> Ideally I see curses frontend script renamed to `bpython-curses`, and
> `bpython` becoming a script that runs autodetection steps, lists
> frontends and can be used to query enabled/disabled (i.e. implemented)
> features for these frontends. I still don't know if it's possible.
I don't see the advantages of that approach. I neither expect that
bpython has a billion different frontends somewhere near in the future
nor that users switch frontends all the time. I also think that
different frontends serve different needs. For example the bpython-gtk
can be embedded in other X11 aplications or (more or less easy) used
directly as gtk widget.
Regards,
Andreas
--
You received this message because you are subscribed to the Google Groups
"bpython" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/bpython?hl=en.
