Re: app termination / ns resources

Re: app termination / ns resources

[Adrian Robert]

[cc'ing emacs-devel]


> Also, I have a removed the NS resources and also the ns-expand- 
> lines business, which helped with the interrupted pattern in the  
> fringe for some (but not all) fonts.  I will test this a little  
> more and check it in later this week.

One final dying thought about this ;) -- the way it was prefs-panel <- 
 > ns defaults <-> platform-specific settings was a neat way of  
keeping the NS-specific stuff, be it line spacing or modifier keys,  
out of .emacs, etc. so they would not interfere when moving a .emacs  
across platforms.

As some of these were or are being brought up to the core level, this  
path can and should go away. However, what WILL be remaining platform- 
specific after the current round are:

- modifier key settings
- system highlight color switch
- antialiasing switch
- quickdraw smoothing switch

As these get moved to .emacs, it is important to make sure settings  
for these don't pollute it in a way so as to cause migration  
problems.  I don't know but it would be nice if there were some way  
to use .emacs and core customization but have these settings  
conditionalized on whether the variables exist, or whether the  
windowing system is 'ns.

Finally, the face color setting system will still need to be changed  
to use the .emacs path.

Re: app termination / ns resources

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

On Mar 11, 2009, at 5:59 AM, Adrian Robert wrote:
>
> One final dying thought about this ;) -- the way it was prefs-panel  
> <-> ns defaults <-> platform-specific settings was a neat way of  
> keeping the NS-specific stuff, be it line spacing or modifier keys,  
> out of .emacs, etc. so they would not interfere when moving a .emacs  
> across platforms.

Yes, but the technical distinction of what is available across  
platforms is not a user-level category that merits aggregating these  
functions in a panel (vs. Emacs customization vs. Options menu vs.  
Lisp variables).

In .emacs, users do (when (eq initial-window-system 'ns) ...).

> As these get moved to .emacs, it is important to make sure settings  
> for these don't pollute it in a way so as to cause migration  
> problems.  I don't know but it would be nice if there were some way  
> to use .emacs and core customization but have these settings  
> conditionalized on whether the variables exist, or whether the  
> windowing system is 'ns.

In custom-file, it appears that something like

(custom-set-variables '(foobar 11 t))

will set foobar even if it wasn't defined.  This is the right thing.

> Finally, the face color setting system will still need to be changed  
> to use the .emacs path.

Haven't looked into this, perhaps you or somebody else can give it a  
try.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

Re: app termination / ns resources

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

On Wed, Mar 11, 2009 at 11:59:25AM +0200, Adrian Robert wrote:
> [cc'ing emacs-devel]
>
>
>> Also, I have a removed the NS resources and also the ns-expand-lines 
>> business, which helped with the interrupted pattern in the fringe for some 
>> (but not all) fonts.  I will test this a little more and check it in later 
>> this week.
>
> One final dying thought about this ;) -- the way it was prefs-panel <-> ns 
> defaults <-> platform-specific settings was a neat way of keeping the 
> NS-specific stuff, be it line spacing or modifier keys, out of .emacs, etc. 
> so they would not interfere when moving a .emacs across platforms.
>
> As some of these were or are being brought up to the core level, this path 
> can and should go away. However, what WILL be remaining platform-specific 
> after the current round are:
>
> - modifier key settings
> - system highlight color switch
> - antialiasing switch
> - quickdraw smoothing switch
>
> As these get moved to .emacs, it is important to make sure settings for 
> these don't pollute it in a way so as to cause migration problems.  I don't 
> know but it would be nice if there were some way to use .emacs and core 
> customization but have these settings conditionalized on whether the 
> variables exist, or whether the windowing system is 'ns.

I maintain an emacs across a few different platforms. To do this I use
the following peice of code below.

    (load-user-elisp
      (cond
        ((string-equal "gnu/linux" system-type)  "linux.el")
        ((string-equal "darwin"    system-type)  "darwin.el")))

load-user-elisp is my own function. You would need to convert that to
the Emacs distributed function (load)

For dealing with the whole range of these kinds of issues I made the following
package: http://www.emacswiki.org/emacs/Grail

It would not be a good idea to make the platform specific switch based on
a check of the window system, as Emacs can always run in tty mode and the
test would be broken.

>
> Finally, the face color setting system will still need to be changed to use 
> the .emacs path.
>
>
>
>

-- 
GnuPG Key: B9012279 is available from HKP server pgp.mit.edu

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: app termination / ns resources

[Adrian Robert]

>> As these get moved to .emacs, it is important to make sure  
>> settings for these don't pollute it in a way so as to cause  
>> migration problems.  I don't know but it would be nice if there  
>> were some way to use .emacs and core customization but have these  
>> settings conditionalized on whether the variables exist, or  
>> whether the windowing system is 'ns.
>
> In custom-file, it appears that something like
>
> (custom-set-variables '(foobar 11 t))
>
> will set foobar even if it wasn't defined.  This is the right thing.

OK, good, there's no problem then.

Re: app termination / ns resources

[Adrian Robert]

On Mar 11, 2009, at 6:12 PM, David Reitter wrote:

> On Mar 11, 2009, at 5:59 AM, Adrian Robert wrote:
>>
>> One final dying thought about this ;) -- the way it was prefs- 
>> panel <-> ns defaults <-> platform-specific settings was a neat  
>> way of keeping the NS-specific stuff, be it line spacing or  
>> modifier keys, out of .emacs, etc. so they would not interfere  
>> when moving a .emacs across platforms.
>
> Yes, but the technical distinction of what is available across  
> platforms is not a user-level category that merits aggregating  
> these functions in a panel (vs. Emacs customization vs. Options  
> menu vs. Lisp variables).

I'm not sure about this.  Whether I were using W32 or Mac or anything  
else it makes sense as a user to split these out.  Since if I'm an  
emacs user on other platforms, these will be exactly the things I  
don't know about and might want to set on moving to the new  
platform.  But anway it doesn't matter since it will be removed, I  
was only mentioning it to point out a possible hazard (which turns  
out not to be a hazard) about transitioning to .emacs.

Re: app termination / ns resources

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On Mar 13, 2009, at 12:55 AM, Adrian Robert wrote:

> But anway it doesn't matter since it will be removed, I was only  
> mentioning it to point out a possible hazard (which turns out not to  
> be a hazard) about transitioning to .emacs.

Done.

I also routed the Prefs panel menu item in the applications menu to a  
Lisp-level event, which is bound to customize.

NS preferences loading and saving is (mostly) removed.  I left  
GSFontAntiAlias, because it seems to be a standard under GnuStep, and  
AppleAntiAliasingThreshold for the same reasons on OS X.    Perhaps we  
should have #ifdefs there.

ns-expand-space is gone which is a loss; to counteract that, spacing  
is roughly as it was in the Carbon port (-0.5).  It can be expanded  
via the existing `line-spacing' frame parameter (which works fine for  
me apart from the cursor height).

I hope I didn't miss anything; please get in touch if I did.




[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]