* bug#2532: NS: ns-expand-space / slider in Preferences dialog not functional
@ 2009-03-01 23:52 David Reitter
0 siblings, 0 replies; 30+ messages in thread
From: David Reitter @ 2009-03-01 23:52 UTC (permalink / raw)
To: emacs-pretest-bug
[-- Attachment #1: Type: text/plain, Size: 484 bytes --]
Setting `ns-expand-space' doesn't work, and neither does changing its
value via the slider the the preferences panel.
Also, the doc string of the above variable says that one shouldn't set
it directly - if so, how is one supposed to (programmatically) set this?
Studying the source code (nsterm.m:setValuesFromPanel), it seems to me
that setting the value should work just fine (I even tried calling ns-
save-preferences).
This is with a vanilla 23/NS build from today's CVS.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#2532: NS: ns-expand-space / slider in Preferences dialog not functional
@ 2009-03-04 21:35 Adrian Robert
2009-03-05 3:39 ` David Reitter
2009-03-05 3:39 ` David Reitter
0 siblings, 2 replies; 30+ messages in thread
From: Adrian Robert @ 2009-03-04 21:35 UTC (permalink / raw)
To: 2532; +Cc: David Reitter
> Setting `ns-expand-space' doesn't work, and neither does changing its
> value via the slider the the preferences panel.
>
> Also, the doc string of the above variable says that one shouldn't set
> it directly - if so, how is one supposed to (programmatically) set
> this?
> Studying the source code (nsterm.m:setValuesFromPanel), it seems to me
> that setting the value should work just fine (I even tried calling ns-
> save-preferences).
Emacs must be restarted, unfortunately. It mentions this in the
manual. The variable doc string should be updated.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#2532: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-04 21:35 bug#2532: NS: ns-expand-space / slider in Preferences dialog not functional Adrian Robert
2009-03-05 3:39 ` David Reitter
@ 2009-03-05 3:39 ` David Reitter
1 sibling, 0 replies; 30+ messages in thread
From: David Reitter @ 2009-03-05 3:39 UTC (permalink / raw)
To: Adrian Robert; +Cc: 2532, Emacs-Devel devel
[-- Attachment #1: Type: text/plain, Size: 4588 bytes --]
On 4 Mar 2009, at 16:35, Adrian Robert wrote:
>> Setting `ns-expand-space' doesn't work, and neither does changing its
>> value via the slider the the preferences panel.
>>
>> Also, the doc string of the above variable says that one shouldn't
>> set
>> it directly - if so, how is one supposed to (programmatically) set
>> this?
>> Studying the source code (nsterm.m:setValuesFromPanel), it seems to
>> me
>> that setting the value should work just fine (I even tried calling
>> ns-
>> save-preferences).
>
> Emacs must be restarted, unfortunately. It mentions this in the
> manual. The variable doc string should be updated.
>
The UI does not reflect that. Users need some indication that they
need to restart Emacs for this to work.
The `ns-set-resource' Elisp interface is better than none on the Elisp
side, but what happened to Emacs customization variables?
As said before on this list, introducing another way (beyond .emacs
and customization/custom-file) creates a new failure point for
people's configurations. This is bad in two respects: they won't be
able to reset Emacs to a vanilla state, or troubleshoot a faulty
configuration. And, second, it is going to be harder on us to
troubleshoot people's problems. Right now, with GNU Emacs 22, we have
~/.emacs and ~/.emacs.d (IIRC), and maybe a few site-lisp files. I
speak from experience - in Aquamacs, youthful optimism led me to add
eight further locations for a version of .emacs called Preferences.el
- two would have done the job to satisfy my goal of Mac
compatibility. In addition to that, we split custom-file from .emacs
(a good choice, per se). All of these things make it harder to
support users. "emacs -q" is helpful, but at the end of the day,
people want to run "emacs". Especially seasoned users will complain
that they have to find and delete ~/Library/Preferences/
org.gnu.emacs.plist.
In anticipation of one pro-resource argument: X Resources are much
more limited than the NS parameters system. Why recreate it on NS?
What follows is an excerpt from ns-win.el that shows how many of these
"NS resources" are set.
(ns-set-resource nil "AlternateModifier" (symbol-name ns-alternate-
modifier))
(ns-set-resource nil "CommandModifier" (symbol-name ns-command-
modifier))
(ns-set-resource nil "ControlModifier" (symbol-name ns-control-
modifier))
(ns-set-resource nil "FunctionModifier" (symbol-name ns-function-
modifier))
(ns-set-resource nil "ExpandSpace"
(if ns-expand-space
(number-to-string ns-expand-space)
"NO"))
(ns-set-resource nil "GSFontAntiAlias" (if ns-antialias-text "YES"
"NO"))
(ns-set-resource nil "UseQuickdrawSmoothing"
(if ns-use-qd-smoothing "YES" "NO"))
(ns-set-resource nil "UseSystemHighlightColor"
(if ns-use-system-highlight-color "YES" "NO"))
(ns-set-resource nil "ConfirmQuit"
(if ns-confirm-quit "YES" "NO"))
;; Default frame parameters
(let ((p (frame-parameters))
v)
(if (setq v (assq 'font p))
(ns-set-resource nil "Font" (ns-font-name (cdr v))))
(if (setq v (assq 'fontsize p))
...
(let ((fl (face-list)))
(while (consp fl)
(or (eq 'default (car fl))
;; dont save Default* since it causes all created faces to
;; inherit its values. The properties of the default face
;; have already been saved from the frame-parameters anyway.
(let* ((name (symbol-name (car fl)))
(font (face-font (car fl)))
;; (fontsize (face-fontsize (car fl)))
(foreground (face-foreground (car fl)))
(background (face-background (car fl)))
(underline (face-underline-p (car fl)))
(italic (face-italic-p (car fl)))
(bold (face-bold-p (car fl)))
(stipple (face-stipple (car fl))))
;; (ns-set-resource nil (concat name ".attributeFont")
;; (if font font nil))
;; (ns-set-resource nil (concat name ".attributeFontSize")
;; (if fontsize (number-to-string
fontsize) nil))
(ns-set-resource nil (concat name ".attributeForeground")
(if foreground foreground nil))
(ns-set-resource nil (concat name ".attributeBackground")
(if background background nil))
(ns-set-resource nil (concat name ".attributeUnderline")
...
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-04 21:35 bug#2532: NS: ns-expand-space / slider in Preferences dialog not functional Adrian Robert
@ 2009-03-05 3:39 ` David Reitter
2009-03-06 19:20 ` bug#2532: " Adrian Robert
2009-03-06 19:20 ` Adrian Robert
2009-03-05 3:39 ` David Reitter
1 sibling, 2 replies; 30+ messages in thread
From: David Reitter @ 2009-03-05 3:39 UTC (permalink / raw)
To: Adrian Robert; +Cc: 2532, Emacs-Devel devel
[-- Attachment #1: Type: text/plain, Size: 4588 bytes --]
On 4 Mar 2009, at 16:35, Adrian Robert wrote:
>> Setting `ns-expand-space' doesn't work, and neither does changing its
>> value via the slider the the preferences panel.
>>
>> Also, the doc string of the above variable says that one shouldn't
>> set
>> it directly - if so, how is one supposed to (programmatically) set
>> this?
>> Studying the source code (nsterm.m:setValuesFromPanel), it seems to
>> me
>> that setting the value should work just fine (I even tried calling
>> ns-
>> save-preferences).
>
> Emacs must be restarted, unfortunately. It mentions this in the
> manual. The variable doc string should be updated.
>
The UI does not reflect that. Users need some indication that they
need to restart Emacs for this to work.
The `ns-set-resource' Elisp interface is better than none on the Elisp
side, but what happened to Emacs customization variables?
As said before on this list, introducing another way (beyond .emacs
and customization/custom-file) creates a new failure point for
people's configurations. This is bad in two respects: they won't be
able to reset Emacs to a vanilla state, or troubleshoot a faulty
configuration. And, second, it is going to be harder on us to
troubleshoot people's problems. Right now, with GNU Emacs 22, we have
~/.emacs and ~/.emacs.d (IIRC), and maybe a few site-lisp files. I
speak from experience - in Aquamacs, youthful optimism led me to add
eight further locations for a version of .emacs called Preferences.el
- two would have done the job to satisfy my goal of Mac
compatibility. In addition to that, we split custom-file from .emacs
(a good choice, per se). All of these things make it harder to
support users. "emacs -q" is helpful, but at the end of the day,
people want to run "emacs". Especially seasoned users will complain
that they have to find and delete ~/Library/Preferences/
org.gnu.emacs.plist.
In anticipation of one pro-resource argument: X Resources are much
more limited than the NS parameters system. Why recreate it on NS?
What follows is an excerpt from ns-win.el that shows how many of these
"NS resources" are set.
(ns-set-resource nil "AlternateModifier" (symbol-name ns-alternate-
modifier))
(ns-set-resource nil "CommandModifier" (symbol-name ns-command-
modifier))
(ns-set-resource nil "ControlModifier" (symbol-name ns-control-
modifier))
(ns-set-resource nil "FunctionModifier" (symbol-name ns-function-
modifier))
(ns-set-resource nil "ExpandSpace"
(if ns-expand-space
(number-to-string ns-expand-space)
"NO"))
(ns-set-resource nil "GSFontAntiAlias" (if ns-antialias-text "YES"
"NO"))
(ns-set-resource nil "UseQuickdrawSmoothing"
(if ns-use-qd-smoothing "YES" "NO"))
(ns-set-resource nil "UseSystemHighlightColor"
(if ns-use-system-highlight-color "YES" "NO"))
(ns-set-resource nil "ConfirmQuit"
(if ns-confirm-quit "YES" "NO"))
;; Default frame parameters
(let ((p (frame-parameters))
v)
(if (setq v (assq 'font p))
(ns-set-resource nil "Font" (ns-font-name (cdr v))))
(if (setq v (assq 'fontsize p))
...
(let ((fl (face-list)))
(while (consp fl)
(or (eq 'default (car fl))
;; dont save Default* since it causes all created faces to
;; inherit its values. The properties of the default face
;; have already been saved from the frame-parameters anyway.
(let* ((name (symbol-name (car fl)))
(font (face-font (car fl)))
;; (fontsize (face-fontsize (car fl)))
(foreground (face-foreground (car fl)))
(background (face-background (car fl)))
(underline (face-underline-p (car fl)))
(italic (face-italic-p (car fl)))
(bold (face-bold-p (car fl)))
(stipple (face-stipple (car fl))))
;; (ns-set-resource nil (concat name ".attributeFont")
;; (if font font nil))
;; (ns-set-resource nil (concat name ".attributeFontSize")
;; (if fontsize (number-to-string
fontsize) nil))
(ns-set-resource nil (concat name ".attributeForeground")
(if foreground foreground nil))
(ns-set-resource nil (concat name ".attributeBackground")
(if background background nil))
(ns-set-resource nil (concat name ".attributeUnderline")
...
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#2532: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-05 3:39 ` David Reitter
@ 2009-03-06 19:20 ` Adrian Robert
2009-03-06 19:20 ` Adrian Robert
1 sibling, 0 replies; 30+ messages in thread
From: Adrian Robert @ 2009-03-06 19:20 UTC (permalink / raw)
To: David Reitter; +Cc: 2532, Emacs-Devel devel
On Mar 5, 2009, at 5:39 AM, David Reitter wrote:
> The `ns-set-resource' Elisp interface is better than none on the
> Elisp side, but what happened to Emacs customization variables?
>
> As said before on this list, introducing another way (beyond .emacs
> and customization/custom-file) creates a new failure point for
> people's configurations. This is bad in two respects: they won't
> be able to reset Emacs to a vanilla state, or troubleshoot a faulty
> configuration.
> ...
> All of these things make it harder to support users. "emacs -q" is
> helpful, but at the end of the day, people want to run "emacs".
> Especially seasoned users will complain that they have to find and
> delete ~/Library/Preferences/org.gnu.emacs.plist.
This is no longer true -- running -q or -Q now ignores the plist --
though not X resources, I believe. The one difference between the NS
defaults and X resources is that the defaults system is read/write,
whereas X resources are for some strange reason read-only by design.
After various discussion here, I now believe this difference is
fundamental, and that the NS defaults system should therefore be used
in Emacs only internally for parameters that are specific to NS and
not set by users. This includes reading existing system settings
like anti-aliasing threshold, as well as storing previous directories
and window locations for file open/save dialogs. Completely behind-
the-scenes stuff.
I would advocate transitioning all of the ns-xxx lisp variables that
are not stored in defaults to the customization system.
I am not sure if it is appropriate to do this under pretest,
however. It would be a user-visible change and potentially cause
unexpected side effects.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-05 3:39 ` David Reitter
2009-03-06 19:20 ` bug#2532: " Adrian Robert
@ 2009-03-06 19:20 ` Adrian Robert
2009-03-06 19:35 ` bug#2532: " David Reitter
` (3 more replies)
1 sibling, 4 replies; 30+ messages in thread
From: Adrian Robert @ 2009-03-06 19:20 UTC (permalink / raw)
To: David Reitter; +Cc: 2532, Emacs-Devel devel
On Mar 5, 2009, at 5:39 AM, David Reitter wrote:
> The `ns-set-resource' Elisp interface is better than none on the
> Elisp side, but what happened to Emacs customization variables?
>
> As said before on this list, introducing another way (beyond .emacs
> and customization/custom-file) creates a new failure point for
> people's configurations. This is bad in two respects: they won't
> be able to reset Emacs to a vanilla state, or troubleshoot a faulty
> configuration.
> ...
> All of these things make it harder to support users. "emacs -q" is
> helpful, but at the end of the day, people want to run "emacs".
> Especially seasoned users will complain that they have to find and
> delete ~/Library/Preferences/org.gnu.emacs.plist.
This is no longer true -- running -q or -Q now ignores the plist --
though not X resources, I believe. The one difference between the NS
defaults and X resources is that the defaults system is read/write,
whereas X resources are for some strange reason read-only by design.
After various discussion here, I now believe this difference is
fundamental, and that the NS defaults system should therefore be used
in Emacs only internally for parameters that are specific to NS and
not set by users. This includes reading existing system settings
like anti-aliasing threshold, as well as storing previous directories
and window locations for file open/save dialogs. Completely behind-
the-scenes stuff.
I would advocate transitioning all of the ns-xxx lisp variables that
are not stored in defaults to the customization system.
I am not sure if it is appropriate to do this under pretest,
however. It would be a user-visible change and potentially cause
unexpected side effects.
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#2532: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-06 19:20 ` Adrian Robert
@ 2009-03-06 19:35 ` David Reitter
2009-03-06 19:35 ` David Reitter
` (2 subsequent siblings)
3 siblings, 0 replies; 30+ messages in thread
From: David Reitter @ 2009-03-06 19:35 UTC (permalink / raw)
To: Adrian Robert; +Cc: 2532, Emacs-Devel devel
[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]
On 6 Mar 2009, at 14:20, Adrian Robert wrote:
> This is no longer true -- running -q or -Q now ignores the plist --
> though not X resources, I believe. The one difference between the
> NS defaults and X resources is that the defaults system is read/
> write, whereas X resources are for some strange reason read-only by
> design. After various discussion here, I now believe this
> difference is fundamental, and that the NS defaults system should
> therefore be used in Emacs only internally for parameters that are
> specific to NS and not set by users. This includes reading existing
> system settings like anti-aliasing threshold, as well as storing
> previous directories and window locations for file open/save
> dialogs. Completely behind-the-scenes stuff.
Yes, I agree. It's great that there is now a way to access the NS
defaults system.
I would advocate, however, to only use the NS prefs systems for
variables that cannot be implemented with the customization system,
i.e. stuff that needs to be initialized on startup, because user files
are read.
> I am not sure if it is appropriate to do this under pretest,
> however. It would be a user-visible change and potentially cause
> unexpected side effects.
Up to the maintainers to decide:
Is "user-visibility" the right criterion? (Bug fixes are user-visible!)
Shouldn't it be "dangerous" vs. not, and "bug fixes" vs. "features",
and "recent regressions" vs. not?
--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and
support the Aquamacs Project!
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-06 19:20 ` Adrian Robert
2009-03-06 19:35 ` bug#2532: " David Reitter
@ 2009-03-06 19:35 ` David Reitter
2009-03-07 1:09 ` YAMAMOTO Mitsuharu
2009-03-07 1:09 ` bug#2532: " YAMAMOTO Mitsuharu
3 siblings, 0 replies; 30+ messages in thread
From: David Reitter @ 2009-03-06 19:35 UTC (permalink / raw)
To: Adrian Robert; +Cc: 2532, Emacs-Devel devel
[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]
On 6 Mar 2009, at 14:20, Adrian Robert wrote:
> This is no longer true -- running -q or -Q now ignores the plist --
> though not X resources, I believe. The one difference between the
> NS defaults and X resources is that the defaults system is read/
> write, whereas X resources are for some strange reason read-only by
> design. After various discussion here, I now believe this
> difference is fundamental, and that the NS defaults system should
> therefore be used in Emacs only internally for parameters that are
> specific to NS and not set by users. This includes reading existing
> system settings like anti-aliasing threshold, as well as storing
> previous directories and window locations for file open/save
> dialogs. Completely behind-the-scenes stuff.
Yes, I agree. It's great that there is now a way to access the NS
defaults system.
I would advocate, however, to only use the NS prefs systems for
variables that cannot be implemented with the customization system,
i.e. stuff that needs to be initialized on startup, because user files
are read.
> I am not sure if it is appropriate to do this under pretest,
> however. It would be a user-visible change and potentially cause
> unexpected side effects.
Up to the maintainers to decide:
Is "user-visibility" the right criterion? (Bug fixes are user-visible!)
Shouldn't it be "dangerous" vs. not, and "bug fixes" vs. "features",
and "recent regressions" vs. not?
--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and
support the Aquamacs Project!
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#2532: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-06 19:20 ` Adrian Robert
` (2 preceding siblings ...)
2009-03-07 1:09 ` YAMAMOTO Mitsuharu
@ 2009-03-07 1:09 ` YAMAMOTO Mitsuharu
3 siblings, 0 replies; 30+ messages in thread
From: YAMAMOTO Mitsuharu @ 2009-03-07 1:09 UTC (permalink / raw)
To: Adrian Robert; +Cc: David Reitter, 2532, Emacs-Devel devel
>>>>> On Fri, 6 Mar 2009 21:20:13 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:
> I would advocate transitioning all of the ns-xxx lisp variables that
> are not stored in defaults to the customization system.
> I am not sure if it is appropriate to do this under pretest,
> however. It would be a user-visible change and potentially cause
> unexpected side effects.
Emacs already has the line-spacing setting as frame parameter,
buffer-local variable, and text property. So, ns-expand-space
can/should be removed.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-06 19:20 ` Adrian Robert
2009-03-06 19:35 ` bug#2532: " David Reitter
2009-03-06 19:35 ` David Reitter
@ 2009-03-07 1:09 ` YAMAMOTO Mitsuharu
2009-03-07 2:15 ` Adrian Robert
2009-03-07 1:09 ` bug#2532: " YAMAMOTO Mitsuharu
3 siblings, 1 reply; 30+ messages in thread
From: YAMAMOTO Mitsuharu @ 2009-03-07 1:09 UTC (permalink / raw)
To: Adrian Robert; +Cc: David Reitter, 2532, Emacs-Devel devel
>>>>> On Fri, 6 Mar 2009 21:20:13 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:
> I would advocate transitioning all of the ns-xxx lisp variables that
> are not stored in defaults to the customization system.
> I am not sure if it is appropriate to do this under pretest,
> however. It would be a user-visible change and potentially cause
> unexpected side effects.
Emacs already has the line-spacing setting as frame parameter,
buffer-local variable, and text property. So, ns-expand-space
can/should be removed.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-07 1:09 ` YAMAMOTO Mitsuharu
@ 2009-03-07 2:15 ` Adrian Robert
2009-03-07 3:33 ` YAMAMOTO Mitsuharu
2009-03-07 4:27 ` David Reitter
0 siblings, 2 replies; 30+ messages in thread
From: Adrian Robert @ 2009-03-07 2:15 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: David Reitter, Emacs-Devel devel
On Mar 7, 2009, at 3:09 AM, YAMAMOTO Mitsuharu wrote:
>>>>>> On Fri, 6 Mar 2009 21:20:13 +0200, Adrian Robert
>>>>>> <adrian.b.robert@gmail.com> said:
>
>> I would advocate transitioning all of the ns-xxx lisp variables that
>> are not stored in defaults to the customization system.
>
>> I am not sure if it is appropriate to do this under pretest,
>> however. It would be a user-visible change and potentially cause
>> unexpected side effects.
>
> Emacs already has the line-spacing setting as frame parameter,
> buffer-local variable, and text property. So, ns-expand-space
> can/should be removed.
The semantics are different. line-spacing can only be used to
increase line spacing (i.e. add padding between lines). ns-expand-
space can be used to expand or shrink.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-07 2:15 ` Adrian Robert
@ 2009-03-07 3:33 ` YAMAMOTO Mitsuharu
2009-03-07 9:28 ` Adrian Robert
2009-03-07 4:27 ` David Reitter
1 sibling, 1 reply; 30+ messages in thread
From: YAMAMOTO Mitsuharu @ 2009-03-07 3:33 UTC (permalink / raw)
To: Adrian Robert; +Cc: David Reitter, Emacs-Devel devel
>>>>> On Sat, 7 Mar 2009 04:15:05 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:
>> Emacs already has the line-spacing setting as frame parameter,
>> buffer-local variable, and text property. So, ns-expand-space
>> can/should be removed.
> The semantics are different. line-spacing can only be used to
> increase line spacing (i.e. add padding between lines). ns-expand-
> space can be used to expand or shrink.
If shrinking is useful, that should be added in a platform-independent
manner rather than introducing platform-specific variable.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-07 2:15 ` Adrian Robert
2009-03-07 3:33 ` YAMAMOTO Mitsuharu
@ 2009-03-07 4:27 ` David Reitter
1 sibling, 0 replies; 30+ messages in thread
From: David Reitter @ 2009-03-07 4:27 UTC (permalink / raw)
To: Adrian Robert; +Cc: YAMAMOTO Mitsuharu, Emacs-Devel devel
[-- Attachment #1.1: Type: text/plain, Size: 604 bytes --]
On 6 Mar 2009, at 21:15, Adrian Robert wrote:
>> Emacs already has the line-spacing setting as frame parameter,
>> buffer-local variable, and text property. So, ns-expand-space
>> can/should be removed.
>
> The semantics are different. line-spacing can only be used to
> increase line spacing (i.e. add padding between lines). ns-expand-
> space can be used to expand or shrink.
Is there a reason why the default (and ns-expand-space set to 1.0)
results in wider line spacing than with Emacs 22?
Also, note that the cursor position isn't right when the line-spacing
frame parameter is used.
[-- Attachment #1.2: pastedGraphic.png --]
[-- Type: image/png, Size: 78186 bytes --]
[-- Attachment #1.3: Type: text/plain, Size: 2 bytes --]
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-07 3:33 ` YAMAMOTO Mitsuharu
@ 2009-03-07 9:28 ` Adrian Robert
2009-03-08 1:17 ` YAMAMOTO Mitsuharu
0 siblings, 1 reply; 30+ messages in thread
From: Adrian Robert @ 2009-03-07 9:28 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: David Reitter, Emacs-Devel devel
On Mar 7, 2009, at 5:33 AM, YAMAMOTO Mitsuharu wrote:
>
> If shrinking is useful, that should be added in a platform-independent
> manner rather than introducing platform-specific variable.
I find it nice for viewing more lines of code in a window in some
fonts that seem to space fairly generously. If others like it,
perhaps it could be considered for a future version of emacs, using
the existing line-spacing impl as a starting point.
On Mar 7, 2009, at 6:27 AM, David Reitter wrote:
> Is there a reason why the default (and ns-expand-space set to 1.0)
> results in wider line spacing than with Emacs 22?
I'm not sure about Emacs 22 but the original goal was to display
fonts spaced identically to other apps (e.g. TextEdit) on OS X and
GNUstep. This was the case for a while, but testing now, it seems to
be slightly taller. I'm not sure when the regression happened, or of
its cause, but I suspect it may have gotten out of sync late last
summer when the final major round of changes for integrating the new
font backend framework occurred. The relevant (faulty) calculations
are in nsfont_open.
> Also, note that the cursor position isn't right when the line-
> spacing frame parameter is used.
That looks bad. I can't recall any reports on this before, so I'm
not sure also if it's a recent regression or something that never
worked (but was never discovered). Anyway, it should be fixed.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-07 9:28 ` Adrian Robert
@ 2009-03-08 1:17 ` YAMAMOTO Mitsuharu
2009-03-08 17:41 ` Adrian Robert
0 siblings, 1 reply; 30+ messages in thread
From: YAMAMOTO Mitsuharu @ 2009-03-08 1:17 UTC (permalink / raw)
To: Adrian Robert; +Cc: David Reitter, Emacs-Devel devel
>>>>> On Sat, 7 Mar 2009 11:28:28 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:
>> If shrinking is useful, that should be added in a
>> platform-independent manner rather than introducing
>> platform-specific variable.
> I find it nice for viewing more lines of code in a window in some
> fonts that seem to space fairly generously. If others like it,
> perhaps it could be considered for a future version of emacs, using
> the existing line-spacing impl as a starting point.
So, you agree that extending line-spacing is the right direction and
to remove ns-expand-space now? Otherwise it conflicts/duplicates with
line-spacing with respect to expansion even now.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-08 1:17 ` YAMAMOTO Mitsuharu
@ 2009-03-08 17:41 ` Adrian Robert
2009-03-09 0:17 ` YAMAMOTO Mitsuharu
2009-03-09 2:46 ` Miles Bader
0 siblings, 2 replies; 30+ messages in thread
From: Adrian Robert @ 2009-03-08 17:41 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: David Reitter, Emacs-Devel devel
On Mar 8, 2009, at 3:17 AM, YAMAMOTO Mitsuharu wrote:
>>>>>> On Sat, 7 Mar 2009 11:28:28 +0200, Adrian Robert
>>>>>> <adrian.b.robert@gmail.com> said:
>
>>> If shrinking is useful, that should be added in a
>>> platform-independent manner rather than introducing
>>> platform-specific variable.
>
>> I find it nice for viewing more lines of code in a window in some
>> fonts that seem to space fairly generously. If others like it,
>> perhaps it could be considered for a future version of emacs, using
>> the existing line-spacing impl as a starting point.
>
> So, you agree that extending line-spacing is the right direction and
> to remove ns-expand-space now? Otherwise it conflicts/duplicates with
> line-spacing with respect to expansion even now.
I feel the bug with support for line-spacing under NS should be fixed
ASAP, and that eventually, after 23.1, if people try the ns-expand-
space feature under NS and end up liking it / wishing it was present
on other platforms, line-spacing might be extended and expand-space
removed.
I don't see a benefit to removing the latter right now during
pretest, and it would hurt existing users as well as the opportunity
for others to try it out and judge whether it is a feature worth
having in core emacs. There is no conflict with line-spacing -- the
effects can be additive.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-08 17:41 ` Adrian Robert
@ 2009-03-09 0:17 ` YAMAMOTO Mitsuharu
2009-03-09 2:46 ` Miles Bader
1 sibling, 0 replies; 30+ messages in thread
From: YAMAMOTO Mitsuharu @ 2009-03-09 0:17 UTC (permalink / raw)
To: Adrian Robert; +Cc: David Reitter, Emacs-Devel devel
>>>>> On Sun, 8 Mar 2009 19:41:59 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:
>> So, you agree that extending line-spacing is the right direction
>> and to remove ns-expand-space now? Otherwise it
>> conflicts/duplicates with line-spacing with respect to expansion
>> even now.
> I feel the bug with support for line-spacing under NS should be
> fixed ASAP, and that eventually, after 23.1, if people try the
> ns-expand- space feature under NS and end up liking it / wishing it
> was present on other platforms, line-spacing might be extended and
> expand-space removed.
> I don't see a benefit to removing the latter right now during
> pretest, and it would hurt existing users as well as the opportunity
> for others to try it out and judge whether it is a feature worth
> having in core emacs. There is no conflict with line-spacing -- the
> effects can be additive.
I don't understand what is the justification of introducing an
NS-specific variable that overlaps with an existing
platform-independent feature. Aren't you still in the mood that you
are making a private distribution?
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-08 17:41 ` Adrian Robert
2009-03-09 0:17 ` YAMAMOTO Mitsuharu
@ 2009-03-09 2:46 ` Miles Bader
2009-03-09 7:53 ` Adrian Robert
1 sibling, 1 reply; 30+ messages in thread
From: Miles Bader @ 2009-03-09 2:46 UTC (permalink / raw)
To: Adrian Robert; +Cc: David Reitter, YAMAMOTO Mitsuharu, Emacs-Devel devel
Adrian Robert <adrian.b.robert@gmail.com> writes:
> I feel the bug with support for line-spacing under NS should be fixed
> ASAP, and that eventually, after 23.1, if people try the ns-expand-
> space feature under NS and end up liking it / wishing it was present on
> other platforms, line-spacing might be extended and expand-space
> removed.
It's kind of a bad idea to introduce new features in a release, if you
think they'll soon be obsoleted. Why not try to get things right for
this release, and avoid later compatibility headaches?
-Miles
--
Rational, adj. Devoid of all delusions save those of observation, experience
and reflection.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-09 2:46 ` Miles Bader
@ 2009-03-09 7:53 ` Adrian Robert
2009-03-09 9:00 ` YAMAMOTO Mitsuharu
` (2 more replies)
0 siblings, 3 replies; 30+ messages in thread
From: Adrian Robert @ 2009-03-09 7:53 UTC (permalink / raw)
To: Miles Bader; +Cc: David Reitter, YAMAMOTO Mitsuharu, Emacs-Devel devel
On Mar 9, 2009, at 2:17 AM, YAMAMOTO Mitsuharu wrote:
> I don't understand what is the justification of introducing an
> NS-specific variable that overlaps with an existing
> platform-independent feature. Aren't you still in the mood that you
> are making a private distribution?
On Mar 9, 2009, at 4:46 AM, Miles Bader wrote:
> It's kind of a bad idea to introduce new features in a release, if you
> think they'll soon be obsoleted. Why not try to get things right for
> this release, and avoid later compatibility headaches?
I don't have any personal agenda here except that I like the feature
as a user. The "expand-space" feature has been in the NS code for 10
or more years. I didn't introduce it. For the past few years that
I've maintained it on sourceforge, I have however enjoyed the feature
greatly myself. I never knew about line-spacing in core emacs or if
I did it was not of interest to me because I'm usually interested in
shrinking not expanding lines. I wish it were available for the
times I use emacs on X or W32.
But now that the situation is what it is I stand by what I say above:
it doesn't interfere with anything in core emacs (as it is / should
be additive with line-spacing), users benefit from it, and others can
use it to try and see whether it's something that would be worth
having on X and W32. There's no benefit to removing it.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-09 7:53 ` Adrian Robert
@ 2009-03-09 9:00 ` YAMAMOTO Mitsuharu
2009-03-09 9:04 ` Miles Bader
2009-03-09 13:19 ` Stefan Monnier
2 siblings, 0 replies; 30+ messages in thread
From: YAMAMOTO Mitsuharu @ 2009-03-09 9:00 UTC (permalink / raw)
To: Adrian Robert; +Cc: David Reitter, Emacs-Devel devel, Miles Bader
>>>>> On Mon, 9 Mar 2009 09:53:35 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:
> I don't have any personal agenda here except that I like the feature
> as a user. The "expand-space" feature has been in the NS code for
> 10 or more years. I didn't introduce it.
I said "introduce" because the NS code hasn't been a part of the
official Emacs distribution. To become a part of it, the
Cocoa/GNUstep port has to have enough quality such as proper C-g
handling that the port hasn't had for 10 or more years, and reorganize
duplicated/overlapped features.
> For the past few years that I've maintained it on sourceforge, I
> have however enjoyed the feature greatly myself. I never knew about
> line-spacing in core emacs or if I did it was not of interest to me
> because I'm usually interested in shrinking not expanding lines. I
> wish it were available for the times I use emacs on X or W32.
> But now that the situation is what it is I stand by what I say
> above: it doesn't interfere with anything in core emacs (as it is /
> should be additive with line-spacing), users benefit from it, and
> others can use it to try and see whether it's something that would
> be worth having on X and W32. There's no benefit to removing it.
The benefit of removal is apparent: if it is kept, it will introduce
inconsistent multiple interfaces for the same feature when the right
thing is done in a platform-independent way in future. (I think even
the current situation is problematic with respect to expanding.)
That's why we should avoid introducing platform-specific interfaces
for features that are not inherently specific to the platform. I
think the developers of the official Emacs (in contrast to those of
private distributions) should keep that in mind.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-09 7:53 ` Adrian Robert
2009-03-09 9:00 ` YAMAMOTO Mitsuharu
@ 2009-03-09 9:04 ` Miles Bader
2009-03-09 13:19 ` Stefan Monnier
2 siblings, 0 replies; 30+ messages in thread
From: Miles Bader @ 2009-03-09 9:04 UTC (permalink / raw)
To: Adrian Robert; +Cc: David Reitter, YAMAMOTO Mitsuharu, Emacs-Devel devel
Adrian Robert <adrian.b.robert@gmail.com> writes:
> But now that the situation is what it is I stand by what I say above: it
> doesn't interfere with anything in core emacs (as it is / should be
> additive with line-spacing), users benefit from it, and others can use
> it to try and see whether it's something that would be worth having on
> X and W32. There's no benefit to removing it.
We do not want to have to keep supporting multiple redundant interfaces
if we can help it, especially system-dependent ones.
If we don't _remove_ it, but it appears likely that it will merged with
the generic emacs interface (and it that certainly appears like the best
option to me), then at least we shouldn't _advertise_ it (and should
instead put in the doc "don't depend on this, it will go away in the
future").
-Miles
--
Genealogy, n. An account of one's descent from an ancestor who did not
particularly care to trace his own.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-09 7:53 ` Adrian Robert
2009-03-09 9:00 ` YAMAMOTO Mitsuharu
2009-03-09 9:04 ` Miles Bader
@ 2009-03-09 13:19 ` Stefan Monnier
2009-03-09 20:50 ` Adrian Robert
` (2 more replies)
2 siblings, 3 replies; 30+ messages in thread
From: Stefan Monnier @ 2009-03-09 13:19 UTC (permalink / raw)
To: Adrian Robert
Cc: David Reitter, Emacs-Devel devel, YAMAMOTO Mitsuharu, Miles Bader
> But now that the situation is what it is I stand by what I say above: it
> doesn't interfere with anything in core emacs (as it is / should be
> additive with line-spacing), users benefit from it, and others can use it
> to try and see whether it's something that would be worth having on X and
> W32. There's no benefit to removing it.
This would encourage the use of MacOSX to try the feature. As long as
MacOSX is not Free Software, this goes against our goals. Also I think
it's pretty clear that the `line-spacing' feature can be expanded to
cover the featureset of `ns-expand-space' and that it would be good
since it would remove a redundant setting, and bring that feature to
all architectures.
So we should remove ns-expand-space right now. If we can come up with
a clean enough patch to extend line-spacing's semantics, we might be
able to consider it for inclusion in Emacs-23.1, otherwise it'll have to
wait for Emacs-23.2.
Stefan
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-09 13:19 ` Stefan Monnier
@ 2009-03-09 20:50 ` Adrian Robert
2009-03-09 21:29 ` David Reitter
2009-03-09 23:15 ` Dan Nicolaescu
2009-03-10 2:38 ` YAMAMOTO Mitsuharu
2 siblings, 1 reply; 30+ messages in thread
From: Adrian Robert @ 2009-03-09 20:50 UTC (permalink / raw)
To: Stefan Monnier
Cc: David Reitter, Emacs-Devel devel, YAMAMOTO Mitsuharu, Miles Bader
On Mar 9, 2009, at 3:19 PM, Stefan Monnier wrote:
>> But now that the situation is what it is I stand by what I say
>> above: it
>> doesn't interfere with anything in core emacs (as it is / should be
>> additive with line-spacing), users benefit from it, and others can
>> use it
>> to try and see whether it's something that would be worth having
>> on X and
>> W32. There's no benefit to removing it.
>
> This would encourage the use of MacOSX to try the feature. As long as
> MacOSX is not Free Software, this goes against our goals. Also I
> think
> it's pretty clear that the `line-spacing' feature can be expanded to
> cover the featureset of `ns-expand-space' and that it would be good
> since it would remove a redundant setting, and bring that feature to
> all architectures.
>
> So we should remove ns-expand-space right now. If we can come up with
> a clean enough patch to extend line-spacing's semantics, we might be
> able to consider it for inclusion in Emacs-23.1, otherwise it'll
> have to
> wait for Emacs-23.2.
OK.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-09 20:50 ` Adrian Robert
@ 2009-03-09 21:29 ` David Reitter
0 siblings, 0 replies; 30+ messages in thread
From: David Reitter @ 2009-03-09 21:29 UTC (permalink / raw)
To: Adrian Robert
Cc: Emacs-Devel devel, Stefan Monnier, YAMAMOTO Mitsuharu,
Miles Bader
[-- Attachment #1: Type: text/plain, Size: 366 bytes --]
On Mar 9, 2009, at 4:50 PM, Adrian Robert wrote:
>>
>> So we should remove ns-expand-space right now. If we can come up
>> with
>> a clean enough patch to extend line-spacing's semantics, we might be
>> able to consider it for inclusion in Emacs-23.1, otherwise it'll
>> have to
>> wait for Emacs-23.2.
>
> OK.
I'm working on a patch for this issue.
- David
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-09 13:19 ` Stefan Monnier
2009-03-09 20:50 ` Adrian Robert
@ 2009-03-09 23:15 ` Dan Nicolaescu
[not found] ` <jwvvdqihzix.fsf-monnier+emacs@gnu.org>
2009-03-10 2:38 ` YAMAMOTO Mitsuharu
2 siblings, 1 reply; 30+ messages in thread
From: Dan Nicolaescu @ 2009-03-09 23:15 UTC (permalink / raw)
To: Stefan Monnier
Cc: Miles Bader, David Reitter, Adrian Robert, YAMAMOTO Mitsuharu,
Emacs-Devel devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > But now that the situation is what it is I stand by what I say above: it
> > doesn't interfere with anything in core emacs (as it is / should be
> > additive with line-spacing), users benefit from it, and others can use it
> > to try and see whether it's something that would be worth having on X and
> > W32. There's no benefit to removing it.
>
> This would encourage the use of MacOSX to try the feature. As long as
> MacOSX is not Free Software, this goes against our goals. Also I think
> it's pretty clear that the `line-spacing' feature can be expanded to
> cover the featureset of `ns-expand-space' and that it would be good
> since it would remove a redundant setting, and bring that feature to
> all architectures.
>
> So we should remove ns-expand-space right now. If we can come up with
> a clean enough patch to extend line-spacing's semantics, we might be
> able to consider it for inclusion in Emacs-23.1, otherwise it'll have to
> wait for Emacs-23.2.
How about similar features that are in the ns specific files, but should
be generic (if they should be included at all).
When the ns support was included, I sent a few messages with reviews,
and found quite a few such things.
The ones that I remember right away are in nsfns.m
/* FIXME: Because of the typo below, Qbuffered probably never did
anything useful, so it might as well be removed. */
Qbuffered = intern ("bufferd");
staticpro (&Qbuffered);
??? Whis is this kept around?
Qfontsize = intern ("fontsize");
staticpro (&Qfontsize);
What about this one?
DEFVAR_LISP ("ns-icon-type-alist", &Vns_icon_type_alist,
doc: /* Alist of elements (REGEXP . IMAGE) for images of icons associated to frames.
If the title of a frame matches REGEXP, then IMAGE.tiff is
selected as the image of the icon representing the frame when it's
miniaturized. If an element is t, then Emacs tries to select an icon
based on the filetype of the visited file.
The images have to be installed in a folder called English.lproj in the
Emacs folder. You have to restart Emacs after installing new icons.
Example: Install an icon Gnus.tiff and execute the following code
(setq ns-icon-type-alist
(append ns-icon-type-alist
'((\"^\\\\*\\\\(Group\\\\*$\\\\|Summary \\\\|Article\\\\*$\\\\)\"
. \"Gnus\"))))
When you miniaturize a Group, Summary or Article frame, Gnus.tiff will
be used as the image of the icon representing the frame. */);
Vns_icon_type_alist = Fcons (Qt, Qnil);
This definitely looks like it should be generic, or not included at all.
There are a few more in ns-win.el. Like redefining the standard menu structure, but there are more.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-09 13:19 ` Stefan Monnier
2009-03-09 20:50 ` Adrian Robert
2009-03-09 23:15 ` Dan Nicolaescu
@ 2009-03-10 2:38 ` YAMAMOTO Mitsuharu
2009-03-10 3:16 ` Miles Bader
2 siblings, 1 reply; 30+ messages in thread
From: YAMAMOTO Mitsuharu @ 2009-03-10 2:38 UTC (permalink / raw)
To: Stefan Monnier
Cc: David Reitter, Adrian Robert, Emacs-Devel devel, Miles Bader
>>>>> On Mon, 09 Mar 2009 09:19:43 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:
> This would encourage the use of MacOSX to try the feature. As long
> as MacOSX is not Free Software, this goes against our goals.
In this respect, the group 3 in
http://lists.gnu.org/archive/html/emacs-devel/2009-03/msg00123.html
is also a target of immediate removal, assuming that these features
are not added to the other platforms at this timing.
3. NS-only implementation for features that are not inherently specific to NS.
a. preferences panel
b. alpha-component in color specification
c. color image for stipple (cf. tiling patch by Miles Bader)
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-10 2:38 ` YAMAMOTO Mitsuharu
@ 2009-03-10 3:16 ` Miles Bader
2009-03-10 3:38 ` YAMAMOTO Mitsuharu
0 siblings, 1 reply; 30+ messages in thread
From: Miles Bader @ 2009-03-10 3:16 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu
Cc: David Reitter, Adrian Robert, Stefan Monnier, Emacs-Devel devel
YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> a. preferences panel
> b. alpha-component in color specification
> c. color image for stipple (cf. tiling patch by Miles Bader)
Wouldn't we want some of these for non-NS systems?
[Especially the alpha component]
Perhaps some NS features should be merged into the core; even if
currently they lack good backend support, much of the code is probably
in non-backend places, and existing NS support would help keep it from
bit-rotting.
-Miles
--
`The suburb is an obsolete and contradictory form of human settlement'
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-10 3:16 ` Miles Bader
@ 2009-03-10 3:38 ` YAMAMOTO Mitsuharu
0 siblings, 0 replies; 30+ messages in thread
From: YAMAMOTO Mitsuharu @ 2009-03-10 3:38 UTC (permalink / raw)
To: Miles Bader
Cc: David Reitter, Adrian Robert, Stefan Monnier, Emacs-Devel devel
>>>>> On Tue, 10 Mar 2009 12:16:58 +0900, Miles Bader <miles@gnu.org> said:
>> a. preferences panel
>> b. alpha-component in color specification
>> c. color image for stipple (cf. tiling patch by Miles Bader)
> Wouldn't we want some of these for non-NS systems?
> [Especially the alpha component]
Yes. I'd encourage to make a uniform specification/interface toward
Emacs 23.2 or later, in order to avoid compatibility problems in
future. The current alpha-comonent spec in NS is incompatible with
that of XRenderParseColor for example, and such things happen if
platform-independence is not in mind from the beginning.
Even with the uniform spec, there are some glitches in the NS
implementation as reported to the Emacs.app devel list. So, it's a
good chance to defer the bug fixes for the alpha-component support by
dropping it so as to allocate more time for more important fixes at
this timing.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
[not found] ` <jwvvdqihzix.fsf-monnier+emacs@gnu.org>
@ 2009-03-10 15:33 ` Dan Nicolaescu
2009-03-10 15:59 ` Stefan Monnier
0 siblings, 1 reply; 30+ messages in thread
From: Dan Nicolaescu @ 2009-03-10 15:33 UTC (permalink / raw)
To: Stefan Monnier
Cc: Miles Bader, David Reitter, Adrian Robert, YAMAMOTO Mitsuharu,
Emacs-Devel devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > /* FIXME: Because of the typo below, Qbuffered probably never did
> > anything useful, so it might as well be removed. */
> > Qbuffered = intern ("bufferd");
> > staticpro (&Qbuffered);
> > ??? Whis is this kept around?
>
> Feel free to remove such dead code.
>
> > Qfontsize = intern ("fontsize");
> > staticpro (&Qfontsize);
> > What about this one?
>
> What about it?
Isn't dealing with font sizes supposed to be cross-platform?
font.c: font_open_for_lface
[snip]
#ifdef HAVE_NS
if (size == 0)
{
Lisp_Object ffsize = get_frame_param(f, Qfontsize);
size = NUMBERP (ffsize) ? POINT_TO_PIXEL (XINT (ffsize), f->resy) : 0;
}
#endif
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional
2009-03-10 15:33 ` Dan Nicolaescu
@ 2009-03-10 15:59 ` Stefan Monnier
0 siblings, 0 replies; 30+ messages in thread
From: Stefan Monnier @ 2009-03-10 15:59 UTC (permalink / raw)
To: Dan Nicolaescu
Cc: Miles Bader, David Reitter, Adrian Robert, YAMAMOTO Mitsuharu,
Emacs-Devel devel
>> > /* FIXME: Because of the typo below, Qbuffered probably never did
>> > anything useful, so it might as well be removed. */
>> > Qbuffered = intern ("bufferd");
>> > staticpro (&Qbuffered);
>> > ??? Whis is this kept around?
>>
>> Feel free to remove such dead code.
>>
>> > Qfontsize = intern ("fontsize");
>> > staticpro (&Qfontsize);
>> > What about this one?
>>
>> What about it?
> Isn't dealing with font sizes supposed to be cross-platform?
> font.c: font_open_for_lface
> [snip]
> #ifdef HAVE_NS
> if (size == 0)
> {
> Lisp_Object ffsize = get_frame_param(f, Qfontsize);
> size = NUMBERP (ffsize) ? POINT_TO_PIXEL (XINT (ffsize), f->resy) : 0;
> }
> #endif
Yes, but I don't know what this piece of code is supposed to do. It can
probably be removed.
Stefan
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2009-03-10 15:59 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-04 21:35 bug#2532: NS: ns-expand-space / slider in Preferences dialog not functional Adrian Robert
2009-03-05 3:39 ` David Reitter
2009-03-06 19:20 ` bug#2532: " Adrian Robert
2009-03-06 19:20 ` Adrian Robert
2009-03-06 19:35 ` bug#2532: " David Reitter
2009-03-06 19:35 ` David Reitter
2009-03-07 1:09 ` YAMAMOTO Mitsuharu
2009-03-07 2:15 ` Adrian Robert
2009-03-07 3:33 ` YAMAMOTO Mitsuharu
2009-03-07 9:28 ` Adrian Robert
2009-03-08 1:17 ` YAMAMOTO Mitsuharu
2009-03-08 17:41 ` Adrian Robert
2009-03-09 0:17 ` YAMAMOTO Mitsuharu
2009-03-09 2:46 ` Miles Bader
2009-03-09 7:53 ` Adrian Robert
2009-03-09 9:00 ` YAMAMOTO Mitsuharu
2009-03-09 9:04 ` Miles Bader
2009-03-09 13:19 ` Stefan Monnier
2009-03-09 20:50 ` Adrian Robert
2009-03-09 21:29 ` David Reitter
2009-03-09 23:15 ` Dan Nicolaescu
[not found] ` <jwvvdqihzix.fsf-monnier+emacs@gnu.org>
2009-03-10 15:33 ` Dan Nicolaescu
2009-03-10 15:59 ` Stefan Monnier
2009-03-10 2:38 ` YAMAMOTO Mitsuharu
2009-03-10 3:16 ` Miles Bader
2009-03-10 3:38 ` YAMAMOTO Mitsuharu
2009-03-07 4:27 ` David Reitter
2009-03-07 1:09 ` bug#2532: " YAMAMOTO Mitsuharu
2009-03-05 3:39 ` David Reitter
-- strict thread matches above, loose matches on Subject: below --
2009-03-01 23:52 David Reitter
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.