Gloridea On The Stage

그 둘을 동시에 안겨준, 너무나도 강렬한 동영상.
아아, 최고구나.

티스토리에 Syntax Highlighter 를 적용하는 방법은 꽤 많이 찾아볼 수 있다.

다만 문제는 편집할 때 이를 적용하는 게 정말 끔찍할 정도로 힘이 든다는 것이다. 두어번 해보고 나면 다신 해보고 싶지 않을 정도로... 텍스트 편집 모드로 전환해서 하이라이팅 적용할 곳에 pre나 textarea를 적용하고... class 적어주고, name 적어주고...

아무리 읽는 사람의 편의를 고려한다고 해도 이건 쓰는 사람이 너무 고통스럽다.
그래서 북마클릿 형태로 만들었다. -,.-

1. SyntaxHighlighter (javascript) 적용: 이 링크를 우클릭하여 북마크에 추가한다.
2. 글쓰기 모드로 진입한다.
3. 코드를 써넣거나 붙여넣는다.
4. SyntaxHighligher를 적용할 블럭을 드래그하여 선택한다.
5. 저장해둔 북마크를 클릭한다.

이렇게 하면 선택한 텍스트의 태그가 모두 없어지고, 텍스트가 파란 박스 안에 들어간다. 이 파란 박스는 <pre>태그로, 에디터상에서 소스 영역을 구분하기 위해 색을 넣었다. 읽기 화면에서 SyntaxHighligher가 적용되어 보여질 때는 이 선이 보이지 않는다.

이제 좀 코드 입력할 맛 난다.
기본적으로 위 북마클릿은 자바스크립트용이다. 다른 버전은 다음과 같다.

1. C++
2. C#
3. CSS
4. Delphi
5. Java
6. Javascript
7. PHP
8. Python
9. Ruby
10. SQL
11. VB
12. XML/HTML

이걸 모두 다 북마크하는 게 답답하다면, prompt 창으로 언어를 입력 받는 버전을 사용해도 된다. 대신 매번 언어를 적어주는 수고를 감수해야 -,.-;

중요한 건!
이 모든 기능이 Firefox 용이라는 점이다. -,.-
IE용은 차차 만들어볼 예정.... (믿거나 말거나)

소스코드 :

javascript:(function() {
var _ed = document.getElementById('tatterVisualEditor');
var _cw = document.createElement('pre');
_cw.style.border = '1px dotted red';
_cw.setAttribute('name', 'code');
_cw.className = 'javascript';
_ed.contentWindow.getSelection().getRangeAt(0).surroundContents(_cw);
_cw.innerHTML = _cw.innerHTML.replace(/(<\/?p>|<br.*?>)/g, '\n').replace(/<.*?>/g, '');
})();

추가 :
<pre> 태그 내에 글을 작성해도 엔터를 치면 자동으로 <br \>이 삽입되어 원하는 개행문자 대신 태그가 출력되는 문제가 있다.
이를 해결하기 위해서 북마클릿을 하나 더 만들었다.
<pre name="code"> </pre> 안에 있는 <br />들을 모두 찾아 개행문자로 바꿔주는 북마클릿이다. 소스상의 <br />은 건들지 않는다. 꼭 소스를 고치지 않았더라도 HTML 편집모드를 한 번이라도 들어갔다가 나왔을 경우 (나오지 않고 바로 저장하면 상관없지만) BR이 자동으로 붙으므로, 제거해주고 저장해야 한다.

한 번 클릭하면 편집 영역에 있는 모든 소스코드의 BR을 개행문자로 바꿔준다.


추가하는 방법은 위와 동일하다.

소스코드의 BR 제거

소스코드 :

javascript:(function(){ 
    var _ed = document.getElementById('tatterVisualEditor');
    var _pres = _ed.contentWindow.document.getElementsByTagName('pre'); 
    for (var i = 0; i < _pres.length; i++) {
        if (_pres[i].getAttribute('name') != 'code') continue;
        var _brs = _pres[i].getElementsByTagName('br');
        for (var j = _brs.length - 1; j >= 0; j--) {
            _brs[j].parentNode.replaceChild(document.createTextNode('\n'), _brs[j]);
        }
    }
})();

JSONRpcClient.toplevel_ex_handler 에 할당된 함수를 재정의해주면 된다.
기본적으로 toplevel_ex_handler 는 다음과 같이 정의되어 있다.
그래서 기본적으로 callback 에서 에러가 발생하면 alert으로 찍혀버리고 만다.

JSONRpcClient.default_ex_handler = function (e) { alert(e); };
JSONRpcClient.toplevel_ex_handler = JSONRpcClient.default_ex_handler;

그러므로 JSONRpcClient.toplevel_ex_handler 를 다음과 같이 정의하면 firebug 등에서 위치 등을 받을 수 있다.

JSONRpcClient.toplevel_ex_handler = function(e) { throw e; }

이클립스에서 소스 머지 등을 할 때 종종 사용하는 Compare 에디터가 Workspace 의 기본 인코딩과 Project 의 기본 인코딩이 다르면 깨진 글자를 표시한다. 덕분에 UTF-8 문자열이 모조리 깨져보여 고생 좀 했다.

당연히 Workspace의 설정보다 Project의 설정이, Project의 설정보다 File의 설정이 우선해야 하지만, 그렇게 안되나보다. (뭥미)

3.2 때는 파일의 설정이나 프로젝트의 설정을 잘 반영했던 걸로 기억하는데... 뭐가 문젤까. --;

정말 그 여파가 클까? 장기적으로 다음에 많은 피해를 줄까?

조중동의 뉴스 공급은 중단되었지만, 다음 메인화면에서 뉴스가 사라진 것은 아니다. 오늘 일어난 일들에 대한 뉴스가 빈곤한 것도 아니다. 어차피 생산된 뉴스는 수많은 다른 공급자에 의해 쌓이고 있다. 어차피 기자들 머리 (낚시 능력 빼고) 나쁜 건 조중동 여부와 상관 없이 비슷하기 때문에, 개인적으로는 컨텐츠의 품질이 크게 차이난다는 느낌은 받기 어렵다.

포털의 메인 화면에서 뉴스를 보고자 하는 사람들은 "볼 무엇" 이 있으면 되는 것일까, 아니면 "꼭 그 공급자의 컨텐츠"를 필요로 하는 것일까? 다음은 아마 어떻게든 조중동과 원만한 해결을 하려 들겠지만, 그게 여의치 않아서 만약 이러한 사태가 장기적으로 지속된다면, 다음 뉴스는 외면받을까? 혹은 별 타격이 없을까?

만약 별 타격이 없다면, 조중동에게는 - 그리고 여타 언론사들도 마찬가지로 - 심대한 위기를 실증하는 것이 된다. 소비자들의 컨텐츠에 대한 선호가 공급자에 대한 충성심에서 오는 것이 아니라는 이야기이고, 이는 결국 언론의 목줄을 포털이 쥐게 됨을 의미한다는 이야기가 된다.

타격이 크다면? 앞으로도 한동안 기존 언론매체의 힘은 공고하게 유지되겠지. 뭐.

적어도 아직까지는, 별 영향을 받지 않는 듯하다 : http://blog.naver.com/irrue/100052820306 . 오히려 언론사쪽의 유입 트래픽이 타격을 받은 듯.