* On 23.06.2014 05:51 am, Brandon Allbery wrote:
> Actually, IIRC there is a weird Apple bug involving some settings in the
> locale prefpane causing $LANG/$LC_* to not be set correctly in some cases when
> you override some locale settings. This would not then be an xterm bug but
> xterm trying to
On Sun, Jun 22, 2014 at 11:26 PM, Mihai Moldovan wrote:
> In spite of that, maybe MacPorts should ship an
> ${prefix}/etc/X11/Xresources
> file enabling Unicode support by default? UTF-8 locales are the default on
> OS X
> anyway.
>
Actually, IIRC there is a weird Apple bug involving some settin
* On 23.06.2014 05:39 am, David Strubbe wrote:
> How does one make XQuartz's xterm support UTF-8?
Taken from https://wiki.archlinux.org/index.php/Xterm#UTF-8
I'd say putting "XTerm*locale: true" to ${prefix}/etc/X11/Xresources (i.e., in
most cases /opt/local/etc/X11/Xresources) should be enough.
How does one make XQuartz's xterm support UTF-8?
David
On Sun, Jun 22, 2014 at 11:26 PM, Mihai Moldovan wrote:
> * On 23.06.2014 02:12 am, Michael Dickens wrote:
> > That said, it's quite possible that I've messed up my xterm settings
> > somehow, which is causing the locking (me, and David ap
On 2014-6-23 13:21 , Mark Brethen wrote:
>
> On Jun 22, 2014, at 7:19 PM, Christopher Jones
> wrote:
>
>> port:xorg-libX11
>
> Here's a snippet from the log file:
>
> :info:configure -- Looking for C++ include X11/extensions/readdisplay.h
> :info:configure -- Looking for C++ include X11/exten
* On 23.06.2014 02:12 am, Michael Dickens wrote:
> That said, it's quite possible that I've messed up my xterm settings
> somehow, which is causing the locking (me, and David apparently). I
> believe this has to do with how the xterm interprets the streamed
> characters (sort of like setting LANG=
On Jun 22, 2014, at 7:19 PM, Christopher Jones wrote:
> port:xorg-libX11
Here's a snippet from the log file:
:info:configure -- Looking for C++ include X11/extensions/readdisplay.h
:info:configure -- Looking for C++ include X11/extensions/readdisplay.h - not
found
:info:configure -- Looking f
On 23 Jun 2014, at 1:04am, Mark Brethen wrote:
> OCE depends on X11/XQuartz. What commands are needed to check if it has been
> installed?
Don’t. The OCE port should not use (by which I mean link against) any third
party X11 libraries, but instead declare a dependency against the MacPorts one
On Sun, Jun 22, 2014, at 07:43 PM, Mihai Moldovan wrote:
> The "average user" is not even using xterm.
The average user who uses GNU Radio via MacPorts on OSX is using an
xterm; I actually do not know of an OSX GNU Radio user who does not use
an xterm. Many of them are very typical average users
OCE depends on X11/XQuartz. What commands are needed to check if it has been
installed?
Mark
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
* On 22.06.2014 10:47 pm, Michael Dickens wrote:
> I use XQuartz's xterm, which, when used with default settings, locks when one
> of those characters comes up. [...] But, since by default the xterm does not,
> and I require xterm for my work (to get the display correct), and I'm guessing
> the av
On Sun, Jun 22, 2014 at 6:55 PM, Ryan Schmidt
wrote:
>
> On Jun 22, 2014, at 9:54 AM, Kurt Hindenburg wrote:
> > On 6/21/14, 7:20 PM, Ryan Schmidt wrote:
> >> Wouldn't this patch be safe to use on all OS X versions? If so, that
> should be done. This will ensure that someone updating the port on a
On Sun, Jun 22, 2014 at 6:53 PM, Ryan Schmidt
wrote:
> On Jun 22, 2014, at 3:47 PM, Michael Dickens wrote:
>
> > I use XQuartz's xterm, which, when used with default settings, locks
> when one of those characters comes up. That's one reason I switched the
> zmq* ports to use "0" (zero) instead o
On Jun 22, 2014, at 9:54 AM, Kurt Hindenburg wrote:
>
> On 6/21/14, 7:20 PM, Ryan Schmidt wrote:
>> Wouldn't this patch be safe to use on all OS X versions? If so, that should
>> be done. This will ensure that someone updating the port on a version of OS
>> X earlier than Mavericks does not in
On Jun 22, 2014, at 3:47 PM, Michael Dickens wrote:
> I use XQuartz's xterm, which, when used with default settings, locks when one
> of those characters comes up. That's one reason I switched the zmq* ports to
> use "0" (zero) instead of the null character. I know that this does not
> happen
I use XQuartz's xterm, which, when used with default settings, locks
when one of those characters comes up. That's one reason I switched
the zmq* ports to use "0" (zero) instead of the null character. I know
that this does not happen in Apple's Terminal.app, and I'm sure there's
a setting I can pu
Hi Ryan,
I agree that it "should" not be a problem, but it actually crashed both
'port search' and 'svn diff' commands for me which seemed like a pretty
significant problem. Also that character renders in various different ways
(for cat, emacs, etc.), mostly erroneous, so it fails in the goal of
c
On 6/21/14 8:35 PM, Ryan Schmidt wrote:
> On Jun 21, 2014, at 7:53 PM, David Evans wrote:
>
>> On 6/21/14 4:43 PM, Ryan Schmidt wrote:
>>> On Jun 17, 2014, at 6:36 PM, dev...@macports.org wrote:
>>>
Revision
121118
Author
dev...@macports.org
Date
2014-06-17 16:36:12 -
On 6/21/14, 7:29 PM, Ryan Schmidt wrote:
So... 0.6.24 did not build for you? If not, why did you commit it?
Obviously I was confused - I haven't gotten my procedure down for
testing ports - having 3 areas (svn, local ports, system ports) and
keeping track of what's what is a little daunting a
On 6/21/14, 7:20 PM, Ryan Schmidt wrote:
Wouldn't this patch be safe to use on all OS X versions? If so, that
should be done. This will ensure that someone updating the port on a
version of OS X earlier than Mavericks does not inadvertently forget
to update the patch, if needed.
I don't think
20 matches
Mail list logo
