Re: Syntax coloring settings per file extension?
Re: Syntax coloring settings per file extension?
- Subject: Re: Syntax coloring settings per file extension?
- From: "Michael Stauffer (Circular Logic)" <email@hidden>
- Date: Wed, 6 Oct 2010 13:33:17 -0400
Thanks Guilaume,
I tried this, but it didn't work for me:
http://lists.apple.com/archives/xcode-users/2005/Jul/msg00377.html
Has anyone got it working with XCode 3? I had to create the
.../Developer Tools/Specifications folder, so I guess things have
changed since 2005.
Here's an awkward workaround I found. Will try it as a last resort:
http://lists.apple.com/archives/xcode-users/2007/Dec/msg00679.html
It seems odd that this wouldn't be already covered by xcode since it
already has a file types specification section in its prefs.
Cheers,
Michael
>Hello,
>
>You can read through this thread:
>http://lists.apple.com/archives/xcode-users/2009/Nov/msg00188.html
>
>The radar I filed is still open.
>Syntax coloring worked for us but only because we generate our
>Xcode projects.
>If you find a solution, please report!
>
>Guillaume
>
>Le 1 oct. 2010 ` 18:38, Michael Stauffer (Circular Logic) a icrit :
>
>> Hi,
>>
>> Does anyone know how to set the default syntax-coloring / file-type
>> handling by file extension? I'm starting on a project that
>has lots of
>> template files (.txx), and so far in xcode I have to manual
>change the
>> syntax coloring each time I open one. I'd like them to
>always be treated
>> as c++ code when they're opened. Thanks for any advice.
>>
>> Cheers,
>> Michael
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Xcode-users mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>rysalide.fr
>>
>> This email sent to email@hidden
>
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL:
>http://lists.apple.com/pipermail/xcode-users/attachments/201010
04/b1a8a86a/attachment.html
>
>------------------------------
>
>Message: 9
>Date: Mon, 04 Oct 2010 18:48:18 -0400
>From: Thomas Wetmore <email@hidden>
>Subject: Static Analyzer Question -- Suppressing Message in Special
> Circumstances
>To: list Xcode-users <email@hidden>
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=us-ascii
>
>This is a question about the static analyzer.
>
>I wrote a language interpreter as part of a genealogical
>application that allows users to write scripts to define
>reports and other forms of database access and computation.
>During the evaluation phase of the interpreter (when programs
>written in the language are being executed) I follow a strict
>memory management policy where all evaluate methods are
>required to create and return values that have been retained,
>and all higher level evaluate methods (evaluation is
>inherently recursive) are required to release the previously
>retained objects (unless they return them as their own values)
>before they return their own retained values. These evaluate
>methods follow similar rules as copy methods -- all methods
>named "evaluate" return an already retained value, and callers
>to these methods are responsible for releasing the values.
>
>All this is fine until I run the static analyzer in which I
>get a warning from every evaluate method about returning
>retained values, and another warning from every release in an
>evaluate about releasing an unretained value. So many of these
>static analyzer messages are generated that I am worried I
>might miss some legitimate messages.
>
>So my question is, does anyone know of a way to suppress
>particular static analyzer messages in those situations where
>I am breaking the rules, but I know I am, in order to conform
>to another set of conventions?
>
>I have a short blog article about the interpreter outlining
>the memory strategy at:
>
>http://deadendssoftware.blogspot.com/2010/04/deadends-interpret
>er-memory-management.html
>
>Tom Wetmore, Chief Bottle Washer, DeadEnds Software
>
>
>
>------------------------------
>
>Message: 10
>Date: Mon, 4 Oct 2010 16:09:02 -0700
>From: Wim Lewis <email@hidden>
>Subject: Re: Static Analyzer Question -- Suppressing Message in
> Special Circumstances
>To: list Xcode-users <email@hidden>
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=us-ascii
>
>On 4 Oct 2010, at 3:48 PM, Thomas Wetmore wrote:
>> [....] I follow a strict memory management policy where all
>evaluate methods are required to create and return values that
>have been retained, and all higher level evaluate methods
>(evaluation is inherently recursive) are required to release
>the previously retained objects [....]
>>
>> So my question is, does anyone know of a way to suppress
>particular static analyzer messages in those situations where
>I am breaking the rules, but I know I am, in order to conform
>to another set of conventions?
>
>In this specific case, I think you can use the
>NS_RETURNS_RETAINED macro (which is defined to an
>__attribute__ which clang's static analyzer recognizes) to
>tell the analyzer that the method returns a retain-count to
>its caller. This overrides clang's usual behavior of guessing
>based on the method name.
>
>This mechanism isn't as flexible as one might like, but one
>advantage over simply suppressing the diagnostics is that
>clang-sa will now verify that your evaluate methods do in fact
>always return a retained object, and the methods that call
>them do in fact release the returned object, etc.
>
>
>
>
>------------------------------
>
>Message: 11
>Date: Tue, 5 Oct 2010 10:15:56 +0100
>From: Antonio Nunes <email@hidden>
>Subject: Making an installer package (locations and, owner/group)
>To: Xcode-list Users <email@hidden>
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=utf-8
>
>Hi,
>
>I am making an installer for two command-line binaries and a
>GUI application. There are couple of decisions I need to make
>that my research has not yet shed adequate light on:
>
>1. Permissions for the apps. I want the user to be able to
>move/remove the GUI app from the applications folder after
>installation. According to recommendations owner and group
>should be root/admin, but that results in the GUI app not
>being relocatable by the user without entering an admin
>password. What would be the correct owner/group and
>permissions to set in PackageMaker for the GUI app?
>
>2. My current plan is to install the command-line binaries in
>"/usr/local/bin/". Is there a more appropriate place for them,
>or is this fine? The binaries do not have any dependencies
>(other than between themselves). (The requirements are 10.6 or
>greater, and easy access from the command line is desirable.)
>
>-AntC3nio
>
>-----------------------------------------------------------
>And could you keep your heart in wonder
>at the daily miracles of your life,
>your pain would not seem less wondrous
>than your joy.
>
>--Kahlil Gibran
>-----------------------------------------------------------
>
>
>
>
>
>------------------------------
>
>Message: 12
>Date: Tue, 5 Oct 2010 11:34:34 +0200
>From: Jonas Maebe <email@hidden>
>Subject: Re: Making an installer package (locations and, owner/group)
>To: Xcode-list Users <email@hidden>
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
>On 05 Oct 2010, at 11:15, Antonio Nunes wrote:
>
>> 1. Permissions for the apps. I want the user to be able to move/
>> remove the GUI app from the applications folder after installation.
>> According to recommendations owner and group should be root/admin,
>> but that results in the GUI app not being relocatable by the user
>> without entering an admin password. What would be the correct owner/
>> group and permissions to set in PackageMaker for the GUI app?
>
>Make everything also group-readable/writable.
>
>> 2. My current plan is to install the command-line binaries in "/usr/
>> local/bin/". Is there a more appropriate place for them, or is this
>> fine?
>
>That's the most appropriate place (see "man hier" and search
>for local).
>
>
>Jonas
>
>
>------------------------------
>
>Message: 13
>Date: Tue, 5 Oct 2010 11:50:04 +0100
>From: Antonio Nunes <email@hidden>
>Subject: Re: Making an installer package (locations and, owner/group)
>To: Jonas Maebe <email@hidden>
>Cc: Xcode-list Users <email@hidden>
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=utf-8
>
>On 5 Oct 2010, at 10:34, Jonas Maebe wrote:
>
>>> 1. Permissions for the apps. I want the user to be able to
>move/remove the GUI app from the applications folder after
>installation. According to recommendations owner and group
>should be root/admin, but that results in the GUI app not
>being relocatable by the user without entering an admin
>password. What would be the correct owner/group and
>permissions to set in PackageMaker for the GUI app?
>>
>> Make everything also group-readable/writable.
>>
>>> 2. My current plan is to install the command-line binaries
>in "/usr/local/bin/". Is there a more appropriate place for
>them, or is this fine?
>>
>> That's the most appropriate place (see "man hier" and search
>for local).
>
>Thanks Jonas, that works fine now.
>
>-AntC3nio
>
>----------------------------------------------------
>It isn't so important to do great things,
>as to do what you do with great love.
>----------------------------------------------------
>
>
>
>
>
>------------------------------
>
>Message: 14
>Date: Tue, 5 Oct 2010 13:06:40 +0200
>From: Christiaan Hofman <email@hidden>
>Subject: Re: Making an installer package (locations and, owner/group)
>To: Jonas Maebe <email@hidden>
>Cc: Xcode-list Users <email@hidden>
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=us-ascii
>
>
>On Oct 5, 2010, at 11:34, Jonas Maebe wrote:
>
>>
>> On 05 Oct 2010, at 11:15, Antonio Nunes wrote:
>>
>>> 1. Permissions for the apps. I want the user to be able to
>move/remove the GUI app from the applications folder after
>installation. According to recommendations owner and group
>should be root/admin, but that results in the GUI app not
>being relocatable by the user without entering an admin
>password. What would be the correct owner/group and
>permissions to set in PackageMaker for the GUI app?
>>
>> Make everything also group-readable/writable.
>>
>
>I would disagree with both of you, based on what I see in my
>Applications folder. I would say that you should get the same
>as a standard installation would give you (i.e. drag&drop from
>a dmg), which means that the owner should be the user. Apple
>installs its apps with root as owner, but it does not make it
>group-writable. So this proposal would not correspond to
>anything that normally happens, therefore I would not
>recommend it. So unless your app needs special privileges for
>some reason, I would say that the owner should be the user.
>
>Christiaan
>
>>> 2. My current plan is to install the command-line binaries
>in "/usr/local/bin/". Is there a more appropriate place for
>them, or is this fine?
>>
>> That's the most appropriate place (see "man hier" and search
>for local).
>>
>>
>> Jonas
>
>
>
>
>------------------------------
>
>Message: 15
>Date: Tue, 5 Oct 2010 12:14:55 +0100
>From: Antonio Nunes <email@hidden>
>Subject: Re: Making an installer package (locations and, owner/group)
>To: Christiaan Hofman <email@hidden>
>Cc: Xcode-list Users <email@hidden>
>Message-ID: <email@hidden>
>Content-Type: text/plain; charset=utf-8
>
>On 5 Oct 2010, at 12:06, Christiaan Hofman wrote:
>
>> I would disagree with both of you, based on what I see in my
>Applications folder. I would say that you should get the same
>as a standard installation would give you (i.e. drag&drop from
>a dmg), which means that the owner should be the user. Apple
>installs its apps with root as owner, but it does not make it
>group-writable. So this proposal would not correspond to
>anything that normally happens, therefore I would not
>recommend it. So unless your app needs special privileges for
>some reason, I would say that the owner should be the user.
>
>Ok, that is what I tried to do, initially, but it did not seem
>to work. What choice from the popup in PackageMaker would
>cause the owner to be the user?
>
>-AntC3nio
>
>----------------------------------------------------
>It is better to light a candle than to curse the darkness
>----------------------------------------------------
>
>
>
>
>
>------------------------------
>
>_______________________________________________
>Xcode-users mailing list
>email@hidden
>http://lists.apple.com/mailman/listinfo/xcode-users
>
>End of Xcode-users Digest, Vol 7, Issue 312
>*******************************************
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden