소스 인사이트의 edit와 view 기능개선(a.k.a. trouble shoot..)

<같이보기>

2019/01/30 - [소프트웨어/소스인사이트 응용] - 소스 인사이트 매크로를 이용한 자동 주석(comment) 만들기..

2019/01/20 - [소프트웨어/소스인사이트 응용] - 소스 인사이트의 특별한 에디트 능력들..

2019/01/17 - [소프트웨어/소스인사이트 응용] - 소스 인사이트가 가지고 있는 검색 기능들..

2019/01/17 - [소프트웨어/소스인사이트 응용] - [tip]소스인사이트 프로젝트 내에서 불필요한 파일 제거하기..

2018/12/15 - [소프트웨어/소스인사이트 응용] - 소스인사이트 설명

<소스 인사이트의 trouble shoot..>

소스 인사이트는 프로그래밍 언어를 분석하고 에디트 하는데 특화된 소프트웨어 툴입니다.

소스 인사이트가 이렇게 가벼울 수 있는 것은, 제가 판단했을 때에는 텍스트 기반의 파일처리와 이를 리스트화 한 것이 큰 요인이지 않을까 싶습니다. 그런데 소스인사이트에서 몇 가지 불편하거나 몰라서 잘 이용하지 못했던 사항들에 대해서 한 번 짚어 보고 가도록 하겠습니다.

1. 한글 코멘트 깨짐 현상 극복

기본적으로 모든 에디터에서 아스키 확장 코드가 아닌 다른 코드들은 텍스트에서 깨짐이 발생할 가능성을 내포하고 있습니다.

소스인사이트는 특히나 한글 코멘트 작성에서 글자가 깨지는 현상이 발생합니다. (물론 4.x 버전을 사용해 보지 않은 저로서는 4.x 버전은 어떤지 잘 모르겠습니다.)

주로 한글의 쌍자음을 입력하는 경우나 쉬프트 누르고 타이핑 시, 또는 한글, ascii 전환 중에 발생합니다.

이 때의 해결책은 깨져 보이는 위치에 커서를 놓고 del 버튼을 눌러 보세요. 

이 방법을 이용하면 한글 코멘트 작성에도 큰 문제는 없을 듯 하네요.

아마도 소스인사이트에서는 한글이 2바이트로 표현되는데 다시 영문(ascii) 모드로 전환 시에 1바이트의 버퍼 오류가 발생한 것이 아닌가 생각되네요.

2. 특정 파일 타입 정의

보통 소스코드는 해당 소스코드에 해당하는 문법을 따릅니다. 또한 그 확장자도 거의 정해져 있죠.

하지만 사용자가 원한다면 C의 경우 .h 가 아닌 다른 확장자를 가지고 include도 충분히 가능하죠.

또는 새롭게 나타난 아두이노와 같은 확장자의 경우 .ino의 확장자를 가지는데 이러한 확장자는 소스인사이트가 어떤 코드의 문법을 따르는지 잘 모릅니다. 이러한 상황에서 사용할 수 있는 팁을 알아 보도록 하겠습니다.

결론은 쉽습니다. Alt + T를 눌러서 Document Options을 들어가 보세요.

좌측 상단에 Document type이 나오는데, 거기에 주요한 문서 타입이 나옵니다. 만일 아두이노 파일들을 C 문법에 따르도록 하고자 한다면, file filter에 기존 *.c; *.h 이던 값을 *.c; *.h; *.ino 로 *.ino 파일 확장자를 추가하면 됩니다.

만일 *.ino 파일가 소스 인사이트 프로젝트에 추가되지 않았다면, Project - Add and Remove Project Files... 를  수행해서 폴더를 클릭한 후에 Show only known documents types를 해제해 준 다음, File name 창에다 *.ino를 치고 엔터, 그후에 Add Tree 버튼으로 프로젝트에 해당 파일을 추가해 줍니다.

3. Style Properties 활용하기..

Style Properties는 각 심볼이 가지는 특징들을 화면상에서 어떻게 보여 줄 지에 대해 설정해 줄 수 있습니다. 

가령 C 언어의 경우, 함수나 변수, 코멘트 등이 사용된 부분에서 어떤 크기, 어떤 색깔로 보여줄 지를 설정해 줄 수 있는 것이죠.

예를 들어 아래 예제에서처럼 변수 정의 위에서 Style Properties를 실행해 보도록 하겠습니다.

현재 uint8_t ledUpdate; 라는 변수가 정의가 되어 있습니다. 이 변수의 이름을 bold 체가 아닌 일반 형태로 전환해 보도록 하겠습니다.

해당 변수에서 마우스 우클릭 - Style Properties를 실행한 후, Bold를 OFF 로 설정해 줍니다.

<Style Properties 적용 전 후 변화 내용>

이외에도 다양한 심볼들에 대해서 보여주기 방식을 바꾸고자 한다면 Style Properties를 수정하여 나만의 가독성 높은 화면을 구현 할 수 있습니다.

단, 짐작하셨듯이, 가령 한개의 전역변수에 style을 변경해 주면, 모든 전역 변수에서도 동일하게 style이 변경된다는 점 참고하시기 바랍니다.

4. inactive 되어 있는 구문..

inactive 되어 있는 구문이란, 아래 이미지와 같이 여러가지 이유로 parsing 되지 않는 symbol이 존재하는 것으로, 대부분의 경우 해당 symbol의 정의가 포함되어 있는 파일이 현재 소스인사이트 프로젝트에 포함되어 있지 않아서 발생합니다. 이외에 하기 7 번의 경우 처럼 parsing이 제대로 이루어지지 않아서 발생하는 경우도 간혹 발생합니다.

이 때에는 해당 파일이 위치하는 곳의 소스코드를 추가해 줌으로써 inactive 되어 있는 구문을 풀어 줄 수 있습니다.

가령 현재 코드에서 보시면 P2OUT 이라는 값이 MCU의 Register 이름인데 관련 header 파일이 소스 인사이트의 프로젝트 내에 포함이 되어 있지 않습니다. 따라서 해당 msp430g2553.h 파일을 추가해 보았습니다.

5. C.tom 파일 손보기..

위 4번에서 우리는 symbol이 정의되지 않은 경우, 해당 심볼이 정의된 파일이 포함되지 않았음을 이해하였습니다.

그런데 4번의 P2OUT이라는 것은 파일을 포함 시켜주었는데 아무리 Ctrl + 마우스 좌클릭을 해도 링크가 연결되지 않아 찾을 수가 없습니다.

이 경우는, 일반 C 코드에서 정의하지 않은 방식으로 심볼을 정의하였기 때문이라고 생각하셔야 합니다.

이 때 사용 할 수 있는 것은, C.tom 파일에 해당 정의 방식을 기입해 주면 됩니다.

msp430g2553.h 파일에서 P2OUT이라는 것을 검색해 보면 다음과 같이 정의 되어 있음을 확인 할 수 있습니다.

SFR_8BIT(P2OUT);                              /* Port 2 Output */

여기에서 SFR_8BIT를 Ctrl + 마우스 좌클릭하시면 아래와 같이 해당 정의로 점프 하는데요.

#define SFR_8BIT(address)   extern volatile unsigned char address

#define SFR_16BIT(address)  extern volatile unsigned int address

#define SFR_32BIT(address)  extern volatile unsigned long address

이 세개의 정의를 C.tom에 추가해 주면 됩니다. 다만, 저도 몇 번의 시행착오를 거쳤는데, 자세히 보시면 P2OUT의 정의 끝에 ;(세미콜론)이 붙어 있는 것이 보이실 것입니다.

따라서 C.tom 파일에서 아래와 같이 맨 아랫줄에 내용을 추가해 주시면 됩니다. 

<C.tom 파일은 아래와 같이 항목을 추가해 주어야 함.>

SFR_8BIT(address);   extern volatile unsigned char address

SFR_16BIT(address);  extern volatile unsigned int address

SFR_32BIT(address);  extern volatile unsigned long address

이 C.tom 파일은 시스템 파일이라서 Ctrl + S로 저장하게 되면 정말 저장할 것인지 한 번 더 묻는 팝업창이 뜹니다. 여기에서는 그냥 yes 라고 쳐 주시면 됩니다.

참고로 C.tom 파일은, C:\Program Files (x86)\Source Insight 3 경로에 있는 것을 열어서 수정해 주셔야 합니다.

(확인해 보니 Program Files 폴더에 있는 파일을 수정하면 User\사용자명\Documents\Source Insight 폴더로 파일을 복사, 갱신하는 것으로 보입니다.)

또한 반드시 Alt + Shift + S 를 눌러 Synchronize 에서 아래 그림처럼 Forced... 로 다시 한 번 전체 코드 심볼을 Sync 해주셔야 합니다.

6. Edit Condition 활용하기..

만일 여러분의 소스 인사이트 프로젝트에 여러가지 전처리 문의 처리 내용이 포함되어 있어 소스가 어떤 부분이 제대로 동작되고 있는지 모르는 경우가 있을 수 있습니다. 즉, 실제 컴파일러에서 사용하는 #define은 하나인데, 소스인사이트의 프로젝트에는 여러가지 경우의 #define이 모두 포함되어 있기 때문에 도무지 어떤 코드가 실제 활용되는지 모르는 경우에 Edit Condition이라는 기능을 사용하면 좋습니다.

이 기능은 코드 자체에 영향을 주지는 않지만 가독성을 위해 #define으로 정의된 값을 임의로 TRUE, FALSE로 지정해주어 화면에서 active code인지 inactive code인지를 알게 해 주는 기능입니다.

아래 에제에서처럼, RO_CSIO_TA2_WDTA라는 정의를 현재 소스인사이트 프로젝트에서는 inactive 된 것처럼 보이게 해 주는 예시입니다.

<Edit Condition Set False 전 후 화면 변화>

7. #define 활용에 의해 발생하는 (중)괄호 개수 차이로 발생되는 화면 parsing 오류

소스 인사이트의 경우에는 사실 중괄호의 숫자에 굉장히 민감히 반응합니다. 가령 제가 파일의 중간 부분에서 코드를 입력하다가 중간에 자칫 중괄호라도 하나 더 들어가게 되면 잠시 후에 화면이 달라지는 것을 보실 수 있을 것입니다.

또한, 가령 다른 사람의 소스코드를 불러와서 분석하는 경우에도 비슷한 화면으로 나타날 수 있습니다.

아래의 경우는 제가 만든 상황이기는 하지만 가운데 처럼 코드를 만들지 마시고, 우측 처럼 코드를 작성하도록 권장드립니다.

지금까지 소스 인사이트의 심볼이 찾아지지 않거나, 원하는 edit 화면이 아닌 상태에서 정상적으로 복구 시키는 방법에 대해 알아보았습니다.

다음 번에는 추가 기능으로 소스 인사이트의 매크로 기능에 대해 자세히 알아보도록 하겠습니다.

<끝>