Visual bell patch for emacs on OSX

Visual bell patch for emacs on OSX

[João Távora]

Hello,

This has probably been discussed here before, but I can't find the
reference. Can someone explain why the following patch:

   https://gist.github.com/capitaomorte/1907807

Cannot be added to src/nsterm.m? Is it a copyright issue, or does it no
longer apply?

Because my two main gripes with emacs on OSX were this and the native
fullscreen. Now we have ns-use-native-fullscreen, we could has well get
rid of that ugly box in the middle...

Thanks,
João

Re: Visual bell patch for emacs on OSX

[Glenn Morris]

The ChangeLog leads me to:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5569

Re: Visual bell patch for emacs on OSX

[Glenn Morris]

Glenn Morris wrote:

> The ChangeLog leads me to:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5569

And browsing emacs-devel around that time leads to

http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00034.html

and subsequent.

Re: Visual bell patch for emacs on OSX

[João Távora]

Glenn Morris <rgm@gnu.org> writes:
> The ChangeLog leads me to:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5569

Oh thanks! (suffice to say I didn't try especially hard, merely googled
some combinations).

So it seems the problem is the GNUstep compatibility. Let's say I
"rework it" with some preprocessor conditionals to apply only to OSX's
cocoa? Do you think it could be accepted then?

Or would I have to rewrite it to work equally well on GNUstep? (that
might take longer, but I can try installing GNUstep on my debian
system).

João

Re: Visual bell patch for emacs on OSX

[Glenn Morris]

I think a solution that simply ifdefs away any GNUstep issue would be
ok. But it seems a copyright assignment was never completed, so the
original patch cannot be used as the basis for anything. And see also
the technical comments from Yamamoto Mitsuharu in emacs-devel 2010-02.
(Frankly it sounds like he probably has a better solution.)

Re: Visual bell patch for emacs on OSX

[Stefan Monnier]

> Or would I have to rewrite it to work equally well on GNUstep?

That would be sweet,


        Stefan

Re: Visual bell patch for emacs on OSX

[François-Xavier Bois]

Before investing time and energy in GNUstep compatibility, are you sure 
any users are using this platform ?

More and more very active emacs developers are using OSX as their main 
os and, in my opinion, it would be sad to slow down the OSX 
compatibility only to be have the pleasure to say that there is a 
GNUstep version of emacs.

Re: Visual bell patch for emacs on OSX

[Jan Djärv]

Hello. 

> 17 dec 2013 kl. 09:35 skrev François-Xavier Bois <fxbois@kernix.com>:
> 
> Before investing time and energy in GNUstep compatibility, are you sure any users are using this platform ?
> 

It does not matter, AFAIK. It is a Gnu project and is to be supported. 
I don't think we ever would sacrifice free software so that non-free systems become easier to maintain. At the very least it provides non-OSX developers with a means of compiling the NS-port. 

     Jan D. 

Re: Visual bell patch for emacs on OSX

[Jan Djärv]

17 dec 2013 kl. 03:11 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

>> Or would I have to rewrite it to work equally well on GNUstep?
> 
> That would be sweet,
> 

That is most likely impossible.  GNUStep lacks a lot of API-functions compared to Cocoa.

	Jan D.

Re: Visual bell patch for emacs on OSX

[Bozhidar Batsov]

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

Seems to me that GNUStep is killing the user experience of the people that are actually using the NS port.  
Maybe this is a policy worth revisiting for the sake of the people that use the NS port?


--  
Cheers,
Bozhidar


On Tuesday, December 17, 2013 at 6:59 PM, Jan Djärv wrote:

>  
> 17 dec 2013 kl. 03:11 skrev Stefan Monnier <monnier@iro.umontreal.ca (mailto:monnier@iro.umontreal.ca)>:
>  
> > > Or would I have to rewrite it to work equally well on GNUstep?
> >  
> > That would be sweet,
>  
> That is most likely impossible. GNUStep lacks a lot of API-functions compared to Cocoa.
>  
> Jan D.  


[-- Attachment #2: Type: text/html, Size: 1446 bytes --]

Re: Visual bell patch for emacs on OSX

[Stefan Monnier]

> Seems to me that GNUStep is killing the user experience of the people that
> are actually using the NS port.

WTF?  How do you get to this conclusion?  The OP has already been told
that it's perfectly OK to just ifdef out the NS-only code.

> Maybe this is a policy worth revisiting for the sake of the people
> that use the NS port?

People who use the NS port and aren't satisfied with it should start
contributing code, because we really don't have nearly
enough contributors.  As Jan pointed out, a non-negligible fraction of
bugs fixed in the NS code are due to Jan who could only do that thanks
to the GNUstep support, so claiming that the GNUstep support is killing
the NS port is ridiculous.


        Stefan

Re: Visual bell patch for emacs on OSX

[Bozhidar Batsov]

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

On Wednesday, December 18, 2013 at 4:21 PM, Stefan Monnier wrote:
> > Seems to me that GNUStep is killing the user experience of the people that
> > are actually using the NS port.
> >  
>  
>  
> WTF? How do you get to this conclusion? The OP has already been told
> that it's perfectly OK to just ifdef out the NS-only code.
>  
>  

I guess I misinterpreted the last few mails in the discussion. I was left under the impression that only
code compatible with GNUStep is eligible for inclusion in Emacs.
>  
> > Maybe this is a policy worth revisiting for the sake of the people
> > that use the NS port?
> >  
>  
>  
> People who use the NS port and aren't satisfied with it should start
> contributing code, because we really don't have nearly
> enough contributors. As Jan pointed out, a non-negligible fraction of
> bugs fixed in the NS code are due to Jan who could only do that thanks
> to the GNUstep support, so claiming that the GNUstep support is killing
> the NS port is ridiculous.
>  
>  

Fair points - I wasn’t aware of the lack of NS contributions. Admittedly I’m not overly familiar with the NS port, having used Emacs mostly on GNU/Linux.  
I know, however, there is some enhanced NS port of Emacs (https://github.com/railwaycat/emacs-mac-port) and I wonder
why aren’t the (some) patches from it applied upstream.

Anyways, I’m dabbling into Objective-C and Cocoa right now. If I manage to grok them I might try to contribute to the NS port.

Please, accept my apologies, if I offended someone. I meant no disrespect.  
>  
>  
> Stefan  


[-- Attachment #2: Type: text/html, Size: 2999 bytes --]

Re: Visual bell patch for emacs on OSX

[Jan Djärv]

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

Hello. 


> 18 dec 2013 kl. 15:52 skrev Bozhidar Batsov <bozhidar@batsov.com>:
> 
> I know, however, there is some enhanced NS port of Emacs (https://github.com/railwaycat/emacs-mac-port) and I wonder
> why aren’t the (some) patches from it applied upstream.

Some code are in trunk, macfont.m.  Most of it uses different APIs and is not worth porting. Some code enable features that don't exist on free platforms, those parts will not be included either 

AFAIK, the author of that port is not interested in porting it to the trunk, so maintenance is an issue as well. 

    Jan D. 

[-- Attachment #2: Type: text/html, Size: 1111 bytes --]

Re: Visual bell patch for emacs on OSX

[João Távora]

Jan Djärv <jan.h.d@swipnet.se> writes:

> 17 dec 2013 kl. 03:11 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
>
>>> Or would I have to rewrite it to work equally well on GNUstep?
>>
>> That would be sweet,
>>
>
> That is most likely impossible.  GNUStep lacks a lot of API-functions
> compared to Cocoa.

Is it really impossible to momentarily (and portably) flash the
header-line/ echo-area in the GNUstep build?

I heroically tried, but failed miserably right away. Building for
GNUstep (--with-ns) errors out in this compilation unit:

   gcc -std=gnu99 -c -Demacs -I. -I. -I../lib -I./../lib -D_REENTRANT -fPIC \
   -fno-strict-aliasing -I/usr/include/GNUstep -I/usr/local/include/GNUstep \
   -I/usr/include/alsa -pthread -I/usr/include/librsvg-2.0                  \
   -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include     \
   -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo                       \
   -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/freetype2 \
   -I/usr/include/libxml2 -I/usr/include/dbus-1.0                           \
   -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -MMD -MF deps/nsterm.d -MP  \
   -I/usr/include/p11-kit-1 -g3 -O2 -fobjc-exceptions -fgnu-runtime         \
   -Wno-import -fconstant-string-class=NSConstantString                     \
   -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGSWARN    \
   -DGSDIAGNOSE nsterm.m

Many errors, at least in today's and recent git clonings

   nsterm.m:6075:1: error: trying to encode non-integer type as a
   bitfield

Besides the reasonably complete toolkit I use to compile for GTK, I'm on
debian wheezy and installed "gnustep-core-devel", version 7.7. Configure
ran fine.

I wonder if these are known pitfalls and if you can point me in the
right direction 

I vaguely remember --with-ns building OK on OSX, but haven't tried
recently.

Thanks,
João

Re: Visual bell patch for emacs on OSX

[Jan Djärv]

Hello.

21 dec 2013 kl. 01:11 skrev João Távora <joaotavora@gmail.com>:

> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> 17 dec 2013 kl. 03:11 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
>> 
>>>> Or would I have to rewrite it to work equally well on GNUstep?
>>> 
>>> That would be sweet,
>>> 
>> 
>> That is most likely impossible.  GNUStep lacks a lot of API-functions
>> compared to Cocoa.
> 
> Is it really impossible to momentarily (and portably) flash the
> header-line/ echo-area in the GNUstep build?
> 

It can be done, but not by simple XOR-ing as is done on other ports.

> I heroically tried, but failed miserably right away. Building for
> GNUstep (--with-ns) errors out in this compilation unit:
> 
>   gcc -std=gnu99 -c -Demacs -I. -I. -I../lib -I./../lib -D_REENTRANT -fPIC \
>   -fno-strict-aliasing -I/usr/include/GNUstep -I/usr/local/include/GNUstep \
>   -I/usr/include/alsa -pthread -I/usr/include/librsvg-2.0                  \
>   -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include     \
>   -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo                       \
>   -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/freetype2 \
>   -I/usr/include/libxml2 -I/usr/include/dbus-1.0                           \
>   -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -MMD -MF deps/nsterm.d -MP  \
>   -I/usr/include/p11-kit-1 -g3 -O2 -fobjc-exceptions -fgnu-runtime         \
>   -Wno-import -fconstant-string-class=NSConstantString                     \
>   -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGSWARN    \
>   -DGSDIAGNOSE nsterm.m
> 
> Many errors, at least in today's and recent git clonings
> 
>   nsterm.m:6075:1: error: trying to encode non-integer type as a
>   bitfield

The GNUStep port compiled fine a couple of days ago, but after that there has been bitfield changes that apparently was not tested.  I'll file a bug report.

	Jan D.

Re: Visual bell patch for emacs on OSX

[martin rudalics]

> Besides the reasonably complete toolkit I use to compile for GTK, I'm on
> debian wheezy and installed "gnustep-core-devel", version 7.7. Configure
> ran fine.

While you're there: Please remember somewhere everything you did to
get this working and pass me the recipe afterwards.

Thanks, martin

Re: Visual bell patch for emacs on OSX

[Jan Djärv]

21 dec 2013 kl. 09:19 skrev Jan Djärv <jan.h.d@swipnet.se>:

> Hello.
> 
> 21 dec 2013 kl. 01:11 skrev João Távora <joaotavora@gmail.com>:
> 
>> I heroically tried, but failed miserably right away. Building for
>> GNUstep (--with-ns) errors out in this compilation unit:
>> 
>>  gcc -std=gnu99 -c -Demacs -I. -I. -I../lib -I./../lib -D_REENTRANT -fPIC \
>>  -fno-strict-aliasing -I/usr/include/GNUstep -I/usr/local/include/GNUstep \
>>  -I/usr/include/alsa -pthread -I/usr/include/librsvg-2.0                  \
>>  -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include     \
>>  -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo                       \
>>  -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/freetype2 \
>>  -I/usr/include/libxml2 -I/usr/include/dbus-1.0                           \
>>  -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -MMD -MF deps/nsterm.d -MP  \
>>  -I/usr/include/p11-kit-1 -g3 -O2 -fobjc-exceptions -fgnu-runtime         \
>>  -Wno-import -fconstant-string-class=NSConstantString                     \
>>  -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGSWARN    \
>>  -DGSDIAGNOSE nsterm.m
>> 
>> Many errors, at least in today's and recent git clonings
>> 
>>  nsterm.m:6075:1: error: trying to encode non-integer type as a
>>  bitfield

I checked in a fix in trunk, please try again.

	Jan D.

Re: Visual bell patch for emacs on OSX

[João Távora]

On Mon, Dec 23, 2013 at 12:09 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> I checked in a fix in trunk, please try again.
>
Thanks.

So I did that and GNUstep emacs compiled OK.

Starting it brings up some kind of top-level menu, a ying-yang-
something square, and emacs itself. I see all my config getting
loaded, the only difference to the GTK case being that it's a little
slower and some fonts look different.

However the big difference is that I can't place the mouse on the
application or give emacs any input. This is apparently some kind of
window-manager issue. Can a gnustep-enabled app be used on top of
normal window managers like fluxbox and stumpwm? If not, what window
manager, if any, should I be using?

Though admittedly I didn't dig a lot, I don't seem to find an answer
to this in

   http://www.gnustep.org/information/aboutGNUstep.html

I understand that gnustep is not a window manager and runs on top of
X11, but then how to manage windows, specifically, how to make input
reach them?

Thanks,
João Távora

Re: Visual bell patch for emacs on OSX

[Jan Djärv]

Hi.

24 dec 2013 kl. 10:56 skrev João Távora <joaotavora@gmail.com>:

> On Mon, Dec 23, 2013 at 12:09 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> I checked in a fix in trunk, please try again.
>> 
> Thanks.
> 
> So I did that and GNUstep emacs compiled OK.
> 
> Starting it brings up some kind of top-level menu, a ying-yang-
> something square, and emacs itself. I see all my config getting
> loaded, the only difference to the GTK case being that it's a little
> slower and some fonts look different.
> 

GNUStep has a general problem with fonts, I have yet to discover how to configure this correctly, if even possible.

> However the big difference is that I can't place the mouse on the
> application or give emacs any input. This is apparently some kind of
> window-manager issue. Can a gnustep-enabled app be used on top of
> normal window managers like fluxbox and stumpwm? If not, what window
> manager, if any, should I be using?

It works fine here with normal window managers (Gnome 3 and Unity).  The GNUStep window manager is WindowMaker.

> 
> Though admittedly I didn't dig a lot, I don't seem to find an answer
> to this in
> 
>   http://www.gnustep.org/information/aboutGNUstep.html
> 
> I understand that gnustep is not a window manager and runs on top of
> X11, but then how to manage windows, specifically, how to make input
> reach them?

Click on them?  That is what I do.

	Jan D.