On 10/24/07, Nils Bruin <[EMAIL PROTECTED]> wrote:
> I understand that the "bg=" hack is a quick way of getting the
> configurability you want, but frankly, I would find it hard to explain
> the existence of that option independent of the very particular usage
> scenario you describe.
To you, since you don't use it, it is a "very particular usage scenario".
To me it is the normal very common (for me at least) usage scenario.
> Jf we want sage to pop up "the appropriate editor", the user should
> not be required to give an extra option like that.
I certainly don't propose that they have to give the extra option.
It is optional. There should still be the default proposal you implemented.
edit(.., bg=None)
does the default
edit(..., bg=True)
does the background = True mode,
edit(..., bg = False)
does the background = False mode.
> In the model I
> proposed (which clearly is inconvenient to you, so we need to see how
> to wrap this), the solution would be to put into your init.sage
> (basically following a suggestion Justin made):
>
> if os.environ.haskey('DISPLAY'):
> sage.misc.edit_module.set_edit_template('emacs +${line} ${file}
> &')
> else:
> sage.misc.edit_module.set_edit_template('emacs +${line} ${file}')
>
> So, if you're sure that this does for emacs what you want, we could
I'm sure that does *not* do what I want. When I login to my laptop
under Linux the DISPLAY environment variable is not even set, yet
emacs pops up in a window. When I login remotely to another machine
(or my laptop, from OS X), it can easily be that DISPLAY is not set.
I also have a similar issue with my office desktop, which I use both
remotely and when I'm actually in my office at the console.
> wrap this into the set_editor command instead of the "bg=" option.
> Then the appropriate magic gets executed if either 'EDITOR=emacs' or
> if set_editor('emacs'), and currently even if edit(..,
> editor='emacs').
>
> Guessing a user's configuration and preferences will stay hackish
> guesswork. I'm happy to put some guesses into set_editor. Ultimately,
> however, people should just put personal configuration stuff into
> init.sage. (either that or every user patches sage.misc.edit_module
^^^^^^^^^
That doesn't work for me, since in my usage the init.sage is the same
in both cases, and I often switch between both usage scenarios.
> Another solution would be two possible "editor templates": emacs-fg
> and emacs-bg.
I just want to type
sage: edit(name)
and have it work. If it happens to be that a window pops up, and will
say to myself -- gee, I need this to be backgrounded so I can type
command still, and I'll instead do
sage; edit(name, bg=True).
Anyway, I can't see the problem with having that option, and your only
argument against it is that "it is difficult to explain in the documentation".
-- William
>
> On Oct 23, 11:03 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> > On 10/22/07, Nils Bruin <[EMAIL PROTECTED]> wrote:
> >
> > > See:
> >
> > >http://sagetrac.org/sage_trac/ticket/768
> >
> > > I have updated the attached patch to be clean against 2.8.8.1. When I
> > > checked the edit() command in sage 2.8.8.1, I realized it was really
> > > broken -- It doesn't work if EDITOR is unset in the environment. The
> > > patch attached to the trac ticket is supposed to fix that.
> >
> > I'm generally happy with this patch, though I don't agree with removing
> > the bg option. Perhaps you're removing that functionality because
> > your particular workflow is more rigid than mine. For example, I use
> > emacs quite a lot, both in a console (especially when I login to other
> > machines), but also as a popup separate application. When I use emacs
> > in console mode, putting the editor in the background is very frusting,
> > and doesn't work at all. When I use emacs as a separate popup application,
> > it
> > is very very frustrating if the console session freezes, since often the
> > reason
> > I'm popping up the editor is to create some examples in the console and
> > paste them into the docstring of a function. In both cases the command
> > name is exactly the same "emacs".
> >
> > So please change the patch back to have the bg option.
> >
> > This is a lot like black on white versus white on black. Most people
> > exclusively
> > use one or the other mode, and it's impossible to know which from the
> > application's point of view. So applications have to support both and
> > make
> > it easy to switch between generating colors for each. I often switch
> > between
> > using emacs and vi, both in window and console mode, and between black
> > on white and white on black, depending on my mood, eye strain, computing
> > I'm logged into, etc. So it needs to be easy to support changing modes.
> > The bg= option to edit is 3 lines of code and does just that; it allows one
> > to
> > very easily override automatic defaults on a per-use basis.
> >
> > -- William
>
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
