OK. Sounds like SAGE will *NOT* be able to read your mind, then. "bg"
option added back in
(can both be used to strip "&" from and to add in "&" to the default).
Ticket reopened.
Thank you for explaining why you need the "bg" option and why the
obvious workarounds don't work in your case.
The "problem" with the options in general is that they clutter the
interface and should be limited to the minimum. Their perceived need
often points to a design flaw. In this case it does too: we are
failing to predict what emacs is going to do. However, as you
describe, it seems too difficult to do so, so I'm happy putting it
back.
On Oct 24, 9:50 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> 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 Washingtonhttp://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/
-~----------~----~----~----~------~----~------~--~---
