Re: SWI-Prolog MacOS app

Having professed my undying commitment to the terminal,
there is one feature from an environment for a another language --
you know, the one with the brackets -- which I quite like, which
is the ability to interpret certain values as composable graphic
elements, see here:
	http://docs.racket-lang.org/quick/
I don't know how useful this is on the long run but it's kind of cool.

Samer.

ps. How do I tell the mailing list I have a new email address?
I must be annoying someone with all these emails that need
'moderator approval'.


On 18 Aug 2013, at 23:22, Richard A. O'Keefe <[email protected]> wrote:

> 
> On 17/08/2013, at 1:00 AM, Abdallah, Samer wrote:
>>> - Double clicking always sends a message to the already running app,
>>>  while I think you want to load the file into a new instance.  So,
>>>  if a running app gets a file-open-event, it now runs
>>> 
>>> 	open -n -a <myself> <file>
>>> 
>>>  Does that make sense?
>> 
>> Generally, multiple instances are the not the Mac OS way of 
>> doing things. I think the standard behaviour would be keep
>> just one instance, open a new window or a new tab with the new
>> file source, and optionally consult the file.
> 
> I would find an automatic consultation of the file always
> disconcerting and occasionally disastrous.  There should not
> be any preference for this.  It should be consistent with
> other programming language processors.  Opening a file that
> is associated with a language processor ensures that the file
> is open in an edit window managed by the processor, and there
> should be a keystroke and/or menu command to compile/evaluate/
> consult/whatever the contents of that window.
> 
> I've used a couple of Prologs on a Mac, and that's how they
> worked.
> 
>> I think that on the whole, GUI apps should not rely on the
>> concept of a 'current directory',
> 
> GUI apps that let the user execute code that uses relative
> file names don't have any choice in the matter.
> 
> Having used "open . -a R" a lot, I wish _every_ programming
> language processor followed that convention.  You have to do
> *something* sensible when the filename you were given is not
> that of a plain file.
> 
>