* Re: NS: ns-expand-space / slider in Preferences dialog not functional [not found] <21F51971-5679-45BF-85A0-D982CA73E722@gmail.com> @ 2009-03-05 3:39 ` David Reitter 2009-03-06 19:20 ` Adrian Robert 0 siblings, 1 reply; 24+ 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] 24+ messages in thread
* Re: NS: ns-expand-space / slider in Preferences dialog not functional 2009-03-05 3:39 ` NS: ns-expand-space / slider in Preferences dialog not functional David Reitter @ 2009-03-06 19:20 ` Adrian Robert 2009-03-06 19:35 ` David Reitter 2009-03-07 1:09 ` YAMAMOTO Mitsuharu 0 siblings, 2 replies; 24+ 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] 24+ 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 ` David Reitter 2009-03-07 1:09 ` YAMAMOTO Mitsuharu 1 sibling, 0 replies; 24+ 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] 24+ 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 ` David Reitter @ 2009-03-07 1:09 ` YAMAMOTO Mitsuharu 2009-03-07 2:15 ` Adrian Robert 1 sibling, 1 reply; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ messages in thread
[parent not found: <jwvvdqihzix.fsf-monnier+emacs@gnu.org>]
* 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ 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; 24+ 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] 24+ messages in thread
end of thread, other threads:[~2009-03-10 15:59 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <21F51971-5679-45BF-85A0-D982CA73E722@gmail.com> 2009-03-05 3:39 ` NS: ns-expand-space / slider in Preferences dialog not functional David Reitter 2009-03-06 19:20 ` Adrian Robert 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
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).