목차
- 1. 해결 안된 문제 및 보류중인 문제
- 2. 기본 css
- 3. 히스토리가 저장안되고 있습니다
- 4. 자료실 문제
- 5. 변환이 안 된 페이지
- 6. 인코딩
- 7. 충돌/병합 문제
- 8. 양손항해
- 9. 속도문제
- 10. MoniWiki와 노스모크모인모인의 랜더링 문제
- 11. 기타
- 11.1. 노스모크 모인모인시대(모인+데이타)는 어디에 있는지요?
- 11.2. 페이지이름바꾸기(Rename Action)가 헛돌기 합니다.
- 11.3. 페이지이름바꾸기(Rename Action)에서 <역링크>는 바뀌지 않습니다.
- 11.4. 페이지이름바꾸기(Rename Action) 결과가 RecentChanges에 곧바로 나타나지 않는데 ...
- 11.5. 페이지이름바꾸기(Rename Action) : 페이지 내용의 마지막 수정자가 페이지를 지운 것처럼 보여지고 있습니다.
- 11.6. 노스모크운영비현황에 거시기를 쓰려거든 로그인을 하라고 합니다.
- 11.7. BadContent
- 12. 아이콘 문제
- 13. data/cache 디렉토리퍼미션
1. 해결 안된 문제 및 보류중인 문제 ¶
FixMoin 액션이 anonymous사용자에게 막혀있습니다.
현재 community class를 쓰고있는듯 한데, 이 부분을 수정해야 할듯.
MoniWiki에는 <설치 설명서>는 바로 보이는데 <사용 설명서>는 찾지 못했습니다. 아무래도 <사용 설명서>를 먼저 보고 해야 할 것 같아요. 맑은이는 지금 맨 땅에 해딩하고 있잖아요. 설명서 공부를 먼저 하는 게 순서일 것 같습니다.
수정 직후 하단에도 <고치기> 명령을 쓸 수 있게 해 줄 수 없는지요?
수정 직후 "상단에는 <고치기><보기> 명령이 둘 다 주어졌습니다." 수정 직후 하단에도 <고치기> 명령을 쓸 수 있게 해 줄 수는 없는지요? 현재는 <보기>만 있습니다.
다시 말해도 같은 말이지만 "하단에도 <고치기><보기> 명령을 둘 다 붙여주면 안 됩니까?" 상단과 똑 같이 말에요.
다른 기능에 관한 이야기는 여기서 배제합니다. 딱 꼬집어 <고치기><보기>만으로 범위를 좁혀 주세요. 간단한 문제인줄 알았는데 그렇지가 않은가 봐요. 애초에 간단한 질문이었거든요.
3. 히스토리가 저장안되고 있습니다 ¶
{{|
지금 히스토리가 전혀 보관되지 않은 상태입니다. 이런 경우, 누군가가 어떤 페이지를 장난하고 저장하면 그 바뀐 페이지만 히스토리가 보관되기때문에 중요한 내용이 날아갈 수 있습니다. 이럴경우 rcs명령을 다음과 같이 실행해주시면 됩니다.
이 작업은 하신 것 같네요. 그런데 몇가지 문제점
지금 히스토리가 전혀 보관되지 않은 상태입니다. 이런 경우, 누군가가 어떤 페이지를 장난하고 저장하면 그 바뀐 페이지만 히스토리가 보관되기때문에 중요한 내용이 날아갈 수 있습니다. 이럴경우 rcs명령을 다음과 같이 실행해주시면 됩니다.
LOGNAME는 $rcs_user에 맞춰줍니다.cd data/text LOGNAME=root ci -l -x,v/ -q -t-"Init." -m"127.0.0.1;;PuzzletChung;;" *|}}
이 작업은 하신 것 같네요. 그런데 몇가지 문제점
- $rcs_user와 LOGNAME을 맞추셨는지요? 이게 맞지 않으면 rcs가 제대로 작동하지 않게됩니다.
- 퍼미션을 모두 쓰기가능으로 고쳐두어야 합니다.
명언을 보려고 안갱(DIFF)를 껴 보면 "옛 버전이 없습니다"(또 점이 없어)라고 나옵니다. "없긴 왜 없어!" 왕짜증을 내면서 안경을 벗어 던지고, 페이지 박물관으로 갔습니다. 페이지 역사(;) 누구의말일까요?아는사람은알지요?)를 보면, 분명히 옛 버전이 달랑 하나 있습니다. 만든 이는 PuzzletChung! 만든 날은 2005년 8월 25일 새벽 5시경! 그러니까 지금은 쓰기만 못하고 있는 게 아니라 읽지도 못한다'''는 이야기 같은 걸요.
어? 방금 봤는데, 그나이땐어떤일을, 이 페이지에 페이지 역사가 만들어지고 있는 바로 이 순간에도! 명언에는 역사를 쓸 수도 읽을 수도 없습니다. 그러니까 지금 이 순간에도, 파일의 속성들이 가지런하지 않고 들쭉 날쭉 하다고 보아야 하는 거지요?
--맑은
고쳤습니다. --PuzzletChung어? 방금 봤는데, 그나이땐어떤일을, 이 페이지에 페이지 역사가 만들어지고 있는 바로 이 순간에도! 명언에는 역사를 쓸 수도 읽을 수도 없습니다. 그러니까 지금 이 순간에도, 파일의 속성들이 가지런하지 않고 들쭉 날쭉 하다고 보아야 하는 거지요?
--맑은
3.1. 지워진 페이지의 DIFF에서 옛버전이 있는데 자꾸만 "옛 버전이 없습니다"라고 해요. ¶
명언과는 또 다른 문제일까요? 옛버전이 있는데 옛버전이 없다고 하는 궁시렁 거림이, 지금 지워져 있는 심리학분류에서도 똑 같이 나타났습니다. DIFF를 누르면 "옛 버전이 없습니다"라고 나오지만 파란아이를 눌러 보면 옛버전이 버젓이 있습니다. 이전의 문제들이 근본적으로 해결되지 못해서 그런 건지요? 아니면 지금은 전혀 다른 문제인가요? 앞으로도 지금 처럼 계속 문제가 보일 때마다 문제를 해결하는 식이 되어야 하는 것인지요? 2005.09.13(화)
이건 모니위키 구현문제이자 버그로 보신 것 같은데, 현재 페이지가 없으면 지워진 것이고, 쓰레기통을 누르면 현재 페이지가 없으므로 보여줄 diff가 없다고 하는게 맞는것 아닐까요? 이것은 마치 diff명령이 두개의 인자를 필요로 하는것과 같은 원리입니다. diff명령은 원래 페이지와 비교 대상의 두개의 페이지가 있어야합니다. 하나가 없으면 diff는 실행 안되죠. 아이콘을 누르면 아예 info로 바로 가게 할 수도 있겠고요. --고무신
으이그, 버그라고 한 게 아니고요, 옛버전이 있는데 왜 없다고 하느냐고 물은 거지요. 고무신님의 설명을 들으니 왜 그렇게 나오는지는 이해가 되었어요. 단지, 있는데 없다고 하는 이유를 알아들었다는 것이지요. 그러니까, 고무신님은 "MoniWiki의 DIFF명령은 이렇게 돌아 갑니다."라고 한 거고 맑은이는 "아, 그래서 그랬었구나" 하며 상황을 이해하고 다음으로 넘어 갑니다. (아참, 맑은이는 버그라고 단정하는 실수를 할지언정 버그라고 단정하지는 않길 바라는 동물입니다. 따라서 고무신님의 오해가 있는 듯하여 해명하려 합니다. 또 아참, 그보다 먼저, 맑은이는 심리학분류를 절대로 지우지 않았음도 강조해 두고요.)
"이것이 버그인가 정책인가" 하는 것은 MoniWiki 자체를 직접적으로 "평가하려 할 때"와 "배우려 할 때"의 물음이 되어야겠지요. 하지만, 지금하는 것은 삼차노스모크이전/문제해결이라는 절차입니다. 따라서 엔진이 바뀐 상태가 먼저 보이는 것이 아니라, 기존에 손에 익었던 기능들이 그대로가 아닌 것이 먼저 보이는 것이지요. 이런 시각의 차이가 있을 수 있다는 것은 충분히 이해하시지요?
끄트머리 사용자로서의 노스모크OnSider들에게는 '버그'가 보이는 것이 아니라 '문제'가 보일 뿐입니다. "![[http]](/ns/imgs/http.png)
저렇게 보이던 것이 이렇게 보입니다." 다르잖아요. 달라졌잖아요. 다르다고요. .png ";)")
음, 노스모크모인모인에서는 "옛버전이 하나만 있는 상태에서 페이지가 지워졌을 때에도 저렇게" 보여줬던 것으로 기억합니다. 그랬기 때문에 그렇게 만들어달라고 때를 쓰고자 함이 아니라, 적어도 "어느 방향이 나은 것인지"에 대한 토의는 할 수 있잖아요?! 토의를 하려면 문제를 끄집어 내 놓아야 할테지요? 지금과 같이 말입니다. 아무튼,
저렇게와 이렇게, 그 다름을, 맑은이는 해결해야 할 문제로 본 것이고, 고무신님에겐 그것이 문제로 보이지 않는 것이었지요. 어쩌면 그건 당연한 일일지도 모릅니다. 그것이 문제일리가 없는 고무신님은 자연스럽게 맑은이가 MoniWiki의 버그를 지적하는 것으로 여길 수 밖에 없었겠지요?! 그러나 아닙니다.
봉착한 문제를 해결하다보니 그 중에는 우연히 MoniWiki의 버그로 판명된 것들도 있고 정책,디자인 등등의 이유들도 있었던 것이었지요. 혹시라도 오해가 있었다면 화끈하게 풀렸으면 좋겠구만요.
이제 남은 문제는 "이 문제를 어떻게 할 것인가?" 입니다. (휴우~)
--맑은
"이것이 버그인가 정책인가" 하는 것은 MoniWiki 자체를 직접적으로 "평가하려 할 때"와 "배우려 할 때"의 물음이 되어야겠지요. 하지만, 지금하는 것은 삼차노스모크이전/문제해결이라는 절차입니다. 따라서 엔진이 바뀐 상태가 먼저 보이는 것이 아니라, 기존에 손에 익었던 기능들이 그대로가 아닌 것이 먼저 보이는 것이지요. 이런 시각의 차이가 있을 수 있다는 것은 충분히 이해하시지요?
끄트머리 사용자로서의 노스모크OnSider들에게는 '버그'가 보이는 것이 아니라 '문제'가 보일 뿐입니다. "
저렇게 보이던 것이 이렇게 보입니다." 다르잖아요. 달라졌잖아요. 다르다고요. 음, 노스모크모인모인에서는 "옛버전이 하나만 있는 상태에서 페이지가 지워졌을 때에도 저렇게" 보여줬던 것으로 기억합니다. 그랬기 때문에 그렇게 만들어달라고 때를 쓰고자 함이 아니라, 적어도 "어느 방향이 나은 것인지"에 대한 토의는 할 수 있잖아요?! 토의를 하려면 문제를 끄집어 내 놓아야 할테지요? 지금과 같이 말입니다. 아무튼, 저렇게와 이렇게, 그 다름을, 맑은이는 해결해야 할 문제로 본 것이고, 고무신님에겐 그것이 문제로 보이지 않는 것이었지요. 어쩌면 그건 당연한 일일지도 모릅니다. 그것이 문제일리가 없는 고무신님은 자연스럽게 맑은이가 MoniWiki의 버그를 지적하는 것으로 여길 수 밖에 없었겠지요?! 그러나 아닙니다.
봉착한 문제를 해결하다보니 그 중에는 우연히 MoniWiki의 버그로 판명된 것들도 있고 정책,디자인 등등의 이유들도 있었던 것이었지요. 혹시라도 오해가 있었다면 화끈하게 풀렸으면 좋겠구만요.
이제 남은 문제는 "이 문제를 어떻게 할 것인가?" 입니다. (휴우~)
--맑은
- 다시 저렇게 만든다.
- 그냥 이렇게 쓴다.
- DIFF아이콘을 누르면 아예 info로 바로 가게 한다.
- 또 다른 의견들...
버그입니다. 버그 맞고요, 제가 의도한 것은 info를 보여주는 것이었는데 그렇게 안돌아가고 있었습니다. 게다가 저는 위에서 말했던것처럼 diff라는 유틸리티가 그렇게 동작하니 그렇게 보여도 그게 이상하지 않은것으로 여기고 버그라는 생각을 전혀 못한것이죠 ^^;;
우선, 아이콘이 예전의 deleted가 아니고 쓰레기통입니다. 사용자가 쓰레기통을 누르는것은 diff를 원하는 것이 아니겠고 그 쓰레기통에 무엇이 있을지 보는것이리라 생각했습니다. 이것은 new아이콘을 눌렀을때 info를 보여주는 것과 같은 이유입니다. 그리고 예전 노스모크모인모인에서는 아이콘이 deleted였으므로 그 아이콘을 누르면 어떻게 보여줘야 하는지는 분명하지 않았습니다. 일단 눌러보고, 아... 지워져서 뻘겋게 다 나오는구나 라고 생각하지 역시 이게 diff의 결과인지 아닌지는 상관하지 않았겠죠.
일단 info로 생각하는것이 맞다고 생각하므로 info로 고쳐놓겠습니다. 혹 예전 노스모크 모인모인과 호환을 생각하는 분이 계시다면 따로 옵션을 만들면 되겠죠..png ":)")
--고무신
4.1. 자료실(UploadedFiles) : 업로드된 파일들의 이름이 이상해요. ¶
UploadedFiles의 파일 목록에서 어떤 파일의 이름은 정상적으로 보이고, 어떤 것은 "!@#$%^&*" 이런류의 이름으로 나오는데요, 이름이 깨진듯이 보이는 그것도 클릭하면 그림이 보여요. "브라우져(익스플로러)->보기->인코딩->한국어" 이렇게 했더니 그 깨진 듯이 보였던 이름들도 모두 잘 보였고, 한글이었습니다. 그것이 잘 보이고 있는 바로 이 때, "항해막대기의 한글"은 모두 다 깨져 보이고요.''' 둘의 인코딩이 일치 하지 않는 모양입니다. 고쳐 주셔유. (당끄) --맑은
4.2. UploadedFiles의 파일 링크 문제 ¶
UploadedFiles의 파일 링크 URL이 변경되었네요. 맑은이가 요번에 UploadedFiles의 파일에 링크를 걸 때 InterMap을 쓰지 않은 죄값을 톡톡히 치뤘습니다. 엉뚱한 짓 좀 하느라 그래 놓은 것이 결국 아까운 시간을 낭비한 결과를 가져왔습니다. 다시는 그런 짓 하지 말아야지, 라고 깊이 반성 중.
이것을 해결하려면
- 파일 이름의 인코딩을 모두 utf-8로 바꾼다. <-- 뭔가요? 맑은이가 하는 거에요? 누가 하는 거에요?
(웃는얼굴에침안뱉겠지) 현재 업로드를 할 수 없게 되어있고 사용자고 쉽게 고칠 수 있거나 할 수 있는 상태가 아닙니다. 일괄적으로 관리자가 고쳐야 하겠지요
- InterMap에서
Uploads:를 조금 고친다.
5.1. 노스모크/모인모인시대에서 어떤 페이지들이 누락 되었는지요? ¶
노스모크/모인모인시대의 마지막 페이지수는 7299 pages입니다. 이주해 온 뒤 [노스모크/모니모니시대가 개벽한 지 한 참 지난 오늘(2005.09.05(월))의 페이지 수가 현재 7260 Pages입니다. 눈에 드러날 정도로 차이가 나므로 뭔가 조치가 있어야 하지 않을까요? "이주 과정에서 어떤 페이지들이 누락되었는지를 알 수 있을까요?" 어떤 페이지들이 누락되었는가를 보면, 프로그램에서 어떤 문제들이 해결되어야 하는지도, 어부지리(?)가 아니라 일석만조(!) 처럼 따라 올라 와 줄 것 같거든요. 아무튼, 기술적인 범주에서의 데이타 이주 작업은 완료 되어야 하는 것 맞지요? --맑은
9/7 아래 두 파일을 프로그램으로 비교해 본 결과 이제 누락된 페이지는 없습니다. --PuzzletChung
- 노스모크모니모니시대 : http://no-smok.net/nsmk/?action=titleindex
- 노스모크모인모인시대 : http://puzzlet.dnip.net:8000/ns/moin.cgi?action=titleindex
지금도, 그대로, 누락된 페이지가 있습니다. 사랑하면알게되고알면보이나니그때에보이는것은전과같지않으리라는 여전히 보이지 않습니다. 위에 제시된 titleindex를 통해서도 "사랑하면알게되고..."는 찾아지지 않습니다.
"혹 프로그램으로 비교할 때 기준을 거꾸로 잡고 하신 게 아니신지요?" 원인이 무엇이든 간에, 현재 누락된 페이지는 분명하게 있으니, 다시 한 번 비교 검토 해 주시길 바랍니다. --맑은 2005.09.08(목)
사랑하면알게되고알게되면보이나니 페이지는 256자 이름길이 제한때문에 옮겨올 수 없습니다. 그래서 페이지 이름을 바꾸고 수동으로 가져오죠.. --고무신
음, PuzzletChung님이 프로그램으로 비교하셨다는 점에 유의해야 할 상황이라고 생각해요. 그러니까, "사랑하면..."페이지를 수동으로 가져왔다고 하여 확인 절차가 끝나는 게 아니잖아요. PuzzletChung님께옵서 "어떤 어떤 페이지만 제외하고 나면, 더 이상 누락된 페이지는 없습니다." 이렇게 응답을 해야 비교하는 일이 끝나는 거잖아요. 무신 얘긴고 하니, 지금의 문제는 고무신의 문제냐 PuzzletChung의 문제냐 하는 것이지요. 또 다시 말해, "두 쪽의 titleindex를 비교하는 과정"에는 모니위키 엔진이 개입하지는 않습니다. 따라서 고무신님의 답변은 이 물음에 대한 대답으로는 충분치가 않습니다. 맞나요? --맑은
이전 전에는 7298페이지입니다.(7299에서 한 페이지를 맑은님이 지웠죠) 그리고 현 7320페이지입니다. 22페이지가 새로 추가된 것인데, 제목을 diff로 살펴보니 새로 만들어진 페이지 목록은 23, (바뀐 이름 3개 미포함)
> BadContent > CommentMacro > FireFox > FireFox/2005-08 > IsbnMap > LocalKeywords > LocalKeywords/CommonWordsKo > MoinToMoni > PI > PZombi > RandomQuoteMacro > RecentChangesMacro > TaggingSystem > dbqp > kspil > unagi > zofox > 공지사항 > 노스모크운영비현황/모인모인시대 > 바투타 > 삼차노스모크이전/문제해결 > 우롱차 > 위키위키모음
5.2. / . _ -가 들어간 페이지가 변환되지 않았습니다. ¶
페이지가 열리지 않습니다.
몇몇 특수문자. / _ -는 페이지 이름 변환과정(?)에서 날(raw)로 그대로 바뀌었습니다. 그래서, 이런 페이지들은 있는데도 없다고 나옵니다. "/"문자가 들어가는 것은 아예 변환되지 않았습니다. 이것들은 모두 각각의 문자에 해당하는 값으로_xx식으로 바뀌어야 합니다.
[-_-] 이 페이지를 열면 이렇게(-%-) 나옵니다. 그래 놓고는 못 찾겠다 꾀꼬리라고 합니다.
[-_-] 페이지의 이름의-%-페이지로 이름이 되어있나봅니다.
5.3. 페이지이름이 너무 길어 변환이 되지 않은 페이지 ¶
6.1. 브라우저의 주소창의 인코딩 문제 ¶
euckr에서 utf8으로 변경되어서 ie의 주소창에 두두둑 적어서는 못 들어옵니다. 또한 no-smok를 interwiki로 지정한 몇몇 위키에선 혼란이 올 수도 있겠네요.
모니위키 1.0.9.2 버전을 깔은 worry입니다. 어제 3차 노스모크에 애플 타이거(OS 10.4) 사파리로 접속해봤는데, 노스모크는 정상적으로 인코딩이 되는데 제 모니위키는 글씨가 보기항목에서 어느 코딩으로해도 깨집니다 ;;. 버전업에 따라 코딩이 달라진 걸까요? 윈도 XP sp2에서 익스플로러, 불여우로 접속하는 것은 _bc_bd로 주소가 뜨고 다 정상적으로 보입니다. 근데 문제는... 바로 윗부분이 지적해주신 인터위키 접속시 글씨가 깨집니다. -_-;;;; 제 생각엔 제 쪽의 코딩을 바꿔야 잘 해결될 문제로 보입니다. 노스모크 모니위키의 버전명과 설치시 달라진 부분을 알 수 있는 페이지를 만들어보면 어떨까요? 일단 정리하자면 이렇게 됩니다. 제 모니위키 토란밭을 1.1 릴리스 버전으로 업그레이드해보고 다시 쓰겠습니다. - worry
;;. 버전업에 따라 코딩이 달라진 걸까요? 윈도 XP sp2에서 익스플로러, 불여우로 접속하는 것은 _bc_bd로 주소가 뜨고 다 정상적으로 보입니다. 근데 문제는... 바로 윗부분이 지적해주신 인터위키 접속시 글씨가 깨집니다. -_-;;;; 제 생각엔 제 쪽의 코딩을 바꿔야 잘 해결될 문제로 보입니다. 노스모크 모니위키의 버전명과 설치시 달라진 부분을 알 수 있는 페이지를 만들어보면 어떨까요? 일단 정리하자면 이렇게 됩니다. 제 모니위키 토란밭을 1.1 릴리스 버전으로 업그레이드해보고 다시 쓰겠습니다. - worry해결했습니다. 제 인터맵설정만 바꾸면 되는 것이었군요. -_-; 다른 곳에서 모니위키에 인터맵을 걸 때 action=goto&ie=UTF-8&oe=EUC-KR&url=http://no-smok.net/nsmk/ 이렇게 하면 되니까 저는 &ie=UTF-8&oe=EUC-KR 부분만 빼면 되는 것이었습니다. OTL ... - worry
| . | OS 타이거 사파리 | XP sp2 익스플로러 | XP sp2 불여우 |
| 토란밭 (모니위키 1.0.9.2) | 유니코드로 글씨정상 (주소창한글이름) | 글씨정상 | 글씨정상 |
| 노스모크 3차 (모니위키 버전?) | 유니코드로 글씨정상(주소창한글이름) | 글씨정상 | 글씨정상 |
6.2. 구글에서의 검색을 고려한 인코딩 방식을 고려해야 ¶
그리고 구글에서 검색했을때 예전 주소 _bc_bd_sd_23과 같은 모인모인식 주소로 검색되는 점도 고민해야할 듯 합니다.
7.1.1. <merge 단추>를 누르면 '<<<<<<' 이런 표시가 있다가 없다가 합니다. ¶
편집중에 충돌되었을 때 <merge> 단추를 누르면 '<<<<<<' 이런 표시가 있다가 없다가 합니다. 그것이 생기는 상태로는 기능을 쓸 수가 없을 것 같아요. 떼어 주는 작업을 별도로 해 줘야 하니까요. 그런데 그 표시가 왜 있다가 없다가 하는 거지요? 어느 상태가 완성된 상태인지를 알 수가 없습니다. 기대 되는 상태가 어떤 것인지를 알려주시고 완성되면 릴뤼즈(?) 선언 해 주셔요. --맑은
merge가 성공적으로 되면 아무 표시가 없고, merge가 실패하면 어느 부분이 이상한지 '<<<<<<'로 표시해주는 것입니다. merge가 동작을 그렇게 합니다. (merge프로그램) 일단, merge가 실패 혹은 성공했다는 메시지를 보여줘야겠군요.
아무튼 merge가 실패를 하는 경우는 순전히 사람의 노동으로 고쳐야 합니다. 예전 노스모크모인모인에서는 어느 부분이 충돌을 나는지 알아야만 고칠 수 있었지만 상황이 조금 나아진 셈이죠. 그러나 노스모크처럼 충돌이 자주 나는 상황에서는 이 방법을 좀 더 영리하게 고치거나, 바뀐 부분을 정확히 지정하거나 하는 방법을 궁리해야겠네요.. --고무신
7.1.2. <merge 단추>를 누른뒤 '<<<<<<' 이런 표시가 나올 때면 텍스트가 더블 됩니다. ¶
항상 그런 건지 그 당시 우연히 그랬는지는 모르겠어요. 아무튼 여러번 보았습니다. --맑은
중복되는 것처럼 보이는 것입니다. merge를 실패하면 conflict가 난다고 하는데 다음과 같은 형식을 가집니다.
<<<<<<< OLD 바뀌기 전 내용 ======= 바뀐 후의 내용 추가된 부분 >>>>>>> NEW
그런데 이게 좀 헷갈린게, 위키위키에서 ===를 태그로 쓰기 때문에 =======가 무슨 위키문법처럼 보인다는 것 때문에 더 어지럽게 보이는 것 같습니다.
아무튼 위의 내용이 떴을 경우, 바뀌기 전의 내용과 바뀐 후의 내용이 무엇이 틀린지 잘 살펴보고 손수 고쳐주는 수밖에 없습니다.
7.1.3. merge 실패했을 때 : <저장> 할 수 없게 해야 ... ¶
merge 실패했을 때 : <메시징> 처리하고 <편집창>의 실패된 내용을 편집창 내에서 보여는 주돼, <저장> 할 수 없게 해야 하는 게 아닌지요. 지금은 텍스트 편집창 안에 깨끗하지 않은 실패한 내용이 그대로 뿌려진 상태에서 저장 할 수 있도록 되어 있어서 상당히 불안합니다. --맑은
저장할 수 없게 할수도 있겠지만 위키위키는 그게 아니더라도 불안한 시스템임은 매 한가지아닐까요? ^^;; 암튼, 충돌할때 자동 merge는 상대편이 내가 편집하고 있는 부분과 전혀 다른 부분을 고치고 있을 경우 상당히 유용합니다. merge성공률이 높아지니까요 --고무신
위키위키가 불안한 시스템이라는 건 그런 의미로 받아 들이지는 않았습니다. 저장하라고 했는데 지워버렸다거나 하는, 기능적으로 불안한 시스템은 아니잖아요. 저장하랬으면 저장하는 것이고, merge하랬으면 머지하는 것이고! 여기까지는 맞지요. 이 흐름을 끊었으면 좋겠다는 게 맑은이의 의견이었습니다. 아무튼 여기서 분명한 것은 "merge 직후에는 반드시 다시 편집해야 한다는 것"입니다. 글이 온전치 않기 때문입니다. 따라서 <저장>단추만 주지 않는다면, 지금 이대로라도, 차이가 나는 부분에 대한 DIFF 메세지를 보여준 것까지라도, 사용자는 얼마든지 고맙게 유용하게 쓸 수가 있습니다.
프로그램이 어떤 구체적인 기능을 사용자에게 주었을 때, 사용자는 그 기능을 믿고 씁니다. 거기에서 실패 가능성을 염두에 두지는 않고 믿고 쓴다는 말입니다. 쓰다고 실패하는 경우가 생기기도 하지만 그것은 뻔히 아는 상황은 아니지요. 아무튼 어떤 작업이 실패를 하더라도, 실패의 흐름 속에서 데이타에 손상이 가해질 수 있음을 고려하지 않습니다. 만약 어떤 작업이 실패했다면 그 트랜잭션은 끝을 내야지 연속하게 되면 문제가 발생할 소지가 크다고 생각합니다. 아는 사람은 쓰던가 안쓰던가 하겠지만, 처음 접하는 사람이 실패한 내용을 그대로 저장해 버린다면 일이 너무 커져 버릴 수가 있는데 이건 사용자의 잘못인가요?
맑은이가 merge를 처음 만났을 때 이런 행동을 보였답니다. 편집 -> 저장 -> 충돌! -> merge -> 저장 이 게 처음 접하는 사람들의 일반적인 흐름 아닐까요? (크흐,일반화오류다!) 그랬더니 저장된 내용이 엉터리가 되어 버린 거에요. 설마, 뭔가 잘못되었다면 문제상황을 알려줬겠지, 그랬으면 더 이상 진행하지 않았을텐데. 페이지의 글은 여기 저기가 중복되어 있고 내가 쓰지 않은 글자까지 마구 들어가 있고. 처음엔 누군가가 같이 편집하고 있는 줄 알고 속으로 그랬죠. "당신, 누구요! 왜 남의 글을 쓰는 도중에 건드리냐!" 그런 다음 내가 쓰지 않은 부분, 나의 동작과는 전혀 관련이 없다고 생각되는 부분을, 지워야 하나 말아야 하나."까지 한참을 고민했습니다. "그래! 지우기로 하자, 지금은 한가지만 생각해." 이러면서 다시 편집창을 열어 손으로 일일이 다 지웠다는 것 아닙니까. 우습죠? 맑은이는 얼마나 심각했다고요. 맑은이가 [맑은] 손으로 분명하게 <merge 단추>를 눌렀지만, merge가 그런 것이라고, 상상이나 했겠어요? 사용자는 프로그래머가 만들어준 기능을 믿고 씁니다. 이 문제는 정말이지 한 번 더 생각해 봐 주신다면 고맙겠어요. --맑은
프로그램이 어떤 구체적인 기능을 사용자에게 주었을 때, 사용자는 그 기능을 믿고 씁니다. 거기에서 실패 가능성을 염두에 두지는 않고 믿고 쓴다는 말입니다. 쓰다고 실패하는 경우가 생기기도 하지만 그것은 뻔히 아는 상황은 아니지요. 아무튼 어떤 작업이 실패를 하더라도, 실패의 흐름 속에서 데이타에 손상이 가해질 수 있음을 고려하지 않습니다. 만약 어떤 작업이 실패했다면 그 트랜잭션은 끝을 내야지 연속하게 되면 문제가 발생할 소지가 크다고 생각합니다. 아는 사람은 쓰던가 안쓰던가 하겠지만, 처음 접하는 사람이 실패한 내용을 그대로 저장해 버린다면 일이 너무 커져 버릴 수가 있는데 이건 사용자의 잘못인가요?
맑은이가 merge를 처음 만났을 때 이런 행동을 보였답니다. 편집 -> 저장 -> 충돌! -> merge -> 저장 이 게 처음 접하는 사람들의 일반적인 흐름 아닐까요? (크흐,일반화오류다!) 그랬더니 저장된 내용이 엉터리가 되어 버린 거에요. 설마, 뭔가 잘못되었다면 문제상황을 알려줬겠지, 그랬으면 더 이상 진행하지 않았을텐데. 페이지의 글은 여기 저기가 중복되어 있고 내가 쓰지 않은 글자까지 마구 들어가 있고. 처음엔 누군가가 같이 편집하고 있는 줄 알고 속으로 그랬죠. "당신, 누구요! 왜 남의 글을 쓰는 도중에 건드리냐!" 그런 다음 내가 쓰지 않은 부분, 나의 동작과는 전혀 관련이 없다고 생각되는 부분을, 지워야 하나 말아야 하나."까지 한참을 고민했습니다. "그래! 지우기로 하자, 지금은 한가지만 생각해." 이러면서 다시 편집창을 열어 손으로 일일이 다 지웠다는 것 아닙니까. 우습죠? 맑은이는 얼마나 심각했다고요. 맑은이가 [맑은] 손으로 분명하게 <merge 단추>를 눌렀지만, merge가 그런 것이라고, 상상이나 했겠어요? 사용자는 프로그래머가 만들어준 기능을 믿고 씁니다. 이 문제는 정말이지 한 번 더 생각해 봐 주신다면 고맙겠어요. --맑은
MoniWiki는 개인위키를 목표로 만들어졌습니다. 당연히 개인위키에서는 merge할 일도 없고 문제점도 잘 드러나지 않겠지요. FreeFeel, TheBrightsKorea에서도 쓰고 있는데 그곳에서는 이 merge의 잠재적 문제점을 지적하지 않더군요. 암튼, 맑은님이 지적했지만 merge의 충돌문제를 제대로 피해갈 방법은 없습니다. 강제로 저장하지 못하게 하는것은 해결법이 아닙니다.
merge에 실패한 부분은 고치전과 고친 후의 정보를 모두 가지고 있으므로 그것을 저장한다고 정보가 소실되는 것이 아니며, 다른 사람이 좀 더 세심하게 고칠 수 있게 됩니다. 그걸 꼭 고쳐서 저장해야 하는 제한이 있게되면 다른 사람과의 협업을 오히려 제한하게 된다는것이죠. merge에 실패했을 경우에 경고를 좀 더 분명하게 보여줘야 하겠고, 어떻게 고쳐야 하는지를 좀 더 설명적으로 보여줘야 하겠군요. --고무신
타협안을 내놓습니다. 먼저 merge를 시도하고, 그 시도가 실패하면 Conflict났다는 경고를 보여주고 merge하지 않습니다. 어디가 바뀌었는지 어디가 conflict났는지만 보여주고, 그 내용은 그대로 둡니다. 이때 "Force merge"라는 버튼이 보이게 됩니다. 이 Force merge를 누르면 강제로 merge하고 예전에 처럼 "<<<<<<" 표시가 textarea에 나타나게 됩니다. 이 경우는 사용자가 무얼 하는지 알고 있고 그걸 수정하려 한다는 것을 전제로 합니다. http://chemie.skku.ac.kr/wiki/wiki.php에서 테스트해보세요. --고무신
merge에 실패한 부분은 고치전과 고친 후의 정보를 모두 가지고 있으므로 그것을 저장한다고 정보가 소실되는 것이 아니며, 다른 사람이 좀 더 세심하게 고칠 수 있게 됩니다. 그걸 꼭 고쳐서 저장해야 하는 제한이 있게되면 다른 사람과의 협업을 오히려 제한하게 된다는것이죠. merge에 실패했을 경우에 경고를 좀 더 분명하게 보여줘야 하겠고, 어떻게 고쳐야 하는지를 좀 더 설명적으로 보여줘야 하겠군요. --고무신
타협안을 내놓습니다. 먼저 merge를 시도하고, 그 시도가 실패하면 Conflict났다는 경고를 보여주고 merge하지 않습니다. 어디가 바뀌었는지 어디가 conflict났는지만 보여주고, 그 내용은 그대로 둡니다. 이때 "Force merge"라는 버튼이 보이게 됩니다. 이 Force merge를 누르면 강제로 merge하고 예전에 처럼 "<<<<<<" 표시가 textarea에 나타나게 됩니다. 이 경우는 사용자가 무얼 하는지 알고 있고 그걸 수정하려 한다는 것을 전제로 합니다. http://chemie.skku.ac.kr/wiki/wiki.php에서 테스트해보세요. --고무신
8.1. 양손항해에서 alt-x는 되는데 'alt-z'가 안돼요. ¶
양손항해 내용을 참고하세요.
양손항해 페이지를 봐도 문제가 해결된 것 같지 않습니다. 페이지 제일 끝으로 갈 때 alt-x를 썼고, 페이지 제일 앞으로 갈 때는 alt-z를 썼 왔었는데 지금 alt-z가 안된다고요. 굉장히 유용했습니다. 마우스를 놓지 않고 항해가 가능하잖아요. 만약 이 기능(alt-z)이 없어진다면 ctrl-HOME을 써야 할 것 같습니다. 그러면 마우스를 손에서 놓아야 하거든요. 안 만들어 줄 겁니까? --맑은
wiki.php소스를 직접 고쳐야만 되는 문제인데 아무튼, 지원하도록 하는것은 간단합니다.
모니위키는 alt-z(zap)대신 alt-s(start) 그리고 <ESC>를 그냥 누르면 goto창으로 가게 되어있습니다. 사용패턴을 바꾸기가 쉽지 않겠지만 alt-x,alt-z대신에 alt-x,alt-s를 누르는 것으로도 가능합니다. --고무신
찾아보니 alt-z는 페이지의 맨 밑으로 가거나 Access key 목록을 보여주는 기능을 하는군요.
wiki.php소스를 직접 고쳐야만 되는 문제인데 아무튼, 지원하도록 하는것은 간단합니다.
모니위키는 alt-z(zap)대신 alt-s(start) 그리고 <ESC>를 그냥 누르면 goto창으로 가게 되어있습니다. 사용패턴을 바꾸기가 쉽지 않겠지만 alt-x,alt-z대신에 alt-x,alt-s를 누르는 것으로도 가능합니다. --고무신
<ESC>는 다른 기능으로 이미 쓰고 있는 거라서, 무진장 헷갈릴 것 같아요. 수정중이던 텍스트를 꺼내주는 키로 쓰로 있는 걸요. 일단 맑은이는 "alt-x,alt-s"에 적응해 보도록 하겠습니다. 표준과 연관된 정책문제라면 alt-z를 꼭 만들어 달란 말은 못하겠습니다. 맑은이 기꺼이 포기할 수 있는 말이지요.
이제야 양손항해 내용을 보란 말이 무슨 내용을 보라는 얘긴지 알 것 같군요. 아래에도 있듯이 alt-x, alt-z 모두 표준 수준에서 이미 예약된 키라면, 이제라도 맑은이는 습관을 바꾸어 보겠습니다.
그렇다면 '맨 위, 맨 아래' 관련 바로가기 키를 새로 정의 해야 하는지요?
암튼, 맑은이는 말씀하신 그런 취지라면 얼마든지 포기할 수 있고, 본래의(?) 예약된 기능으로 기억하도록 손가락 단련을 게을리 하지 않겠습니다. 다만 '맨 위로가기, 맨 아래로 가기'문제는 앞으로 어떻게 진행되어야 할지 의견을 묻는 것이었습니다. 새로 정의해야 하는 건지, 그냥 없는대로 적응해야 하는 건지, 산뜻한 해결책이 있는 건지 등등. (병원가야 해서 오늘은 더 이상 맑은이의 재롱을 보실 수 없습니다. 안녕요~) --맑은
조금 이제야 양손항해 내용을 보란 말이 무슨 내용을 보라는 얘긴지 알 것 같군요. 아래에도 있듯이 alt-x, alt-z 모두 표준 수준에서 이미 예약된 키라면, 이제라도 맑은이는 습관을 바꾸어 보겠습니다.
그렇다면 '맨 위, 맨 아래' 관련 바로가기 키를 새로 정의 해야 하는지요?
암튼, 맑은이는 말씀하신 그런 취지라면 얼마든지 포기할 수 있고, 본래의(?) 예약된 기능으로 기억하도록 손가락 단련을 게을리 하지 않겠습니다. 다만 '맨 위로가기, 맨 아래로 가기'문제는 앞으로 어떻게 진행되어야 할지 의견을 묻는 것이었습니다. 새로 정의해야 하는 건지, 그냥 없는대로 적응해야 하는 건지, 산뜻한 해결책이 있는 건지 등등. (병원가야 해서 오늘은 더 이상 맑은이의 재롱을 보실 수 없습니다. 안녕요~) --맑은
alt-z를 맨 아래로 가기로 하는건 어떤가요? z니까 끝이라는 의미가 있으므로.. 이렇게 되면 기존의 alt-z와 반대의 의미가 되네요. 아무튼 쓸만한 AccessKey를 제안해주시길 
--고무신
--고무신그냥 "alt-z 하나로 <맨 아래, 맨 위> 모두 해결할 수 있다면..." 하고, 바람을 불어 넣어 봅니다. 맨 아래든 맨 위든 zap이라 이 거 아임미껴. 역시 표준문제 때문에 받아들여질 수 없게 되나요? --맑은
alt-z 하나로 위아래 모두 되게 해보았습니다. 단, InternetExplorer에서는 안됩니다. http://chemie.skku.ac.kr/wiki/wiki.php에서 테스트해보세요~ --고무신
테스트를 너무 열심히 해서 그런지 오른쪽 팔에 근육통이 왔습니다. 재해다,재해. 책임져욧! 양손항해 제대로 할 수 있게 해 달란 말에요. 메롱이라고라?엥그리는어케하는겨? x-( (씩씩) (먼가할얘기가있었는데...음...머드라...히드라...페드라...) 아! --맑은양손항해에서 밝혀두었지만, 예전 노스모크에서 쓰던 alt-x는 InternetExplorer에서밖에 쓸 수 없는 기능이었습니다. 그러므로 양손항해에 대한 부분은 예전부터 잠재적으로 있었던 문제점이었습니다. 오른팔에 근육통이 오셨다는건 마우스를 넘 많이 쓰셨다는 말씀이신거 같은데 ㅋㅋ 암튼 테스트 많이 해주세요 =3=3=33 --고무신
찾아보니 alt-z는 페이지의 맨 밑으로 가거나 Access key 목록을 보여주는 기능을 하는군요.9.1. TitleIndex ¶
다른것은 모르겠는데 TitleIndex가 ~10초 이상 걸리는것 같습니다. 그래서 TitleIndex macro를 개선해서 A,B,... 인덱스별로 나누어 보이게끔 하는 옵션을 넣어보니 각 인덱스별로 1초도 안걸리게 나왔습니다. (cvs에 반영)
11.1. 노스모크 모인모인시대(모인+데이타)는 어디에 있는지요? ¶
옛 위키는 이 서버에서 돌리려고 했는데 잘 안 되어서 제 집에 있는 서버에서 돌립니다.
- NoSmoke 모인모인시대 : http://puzzlet.dnip.net:8000/ns/moin.cgi/
- LovolNet 모인모인시대 : http://puzzlet.dnip.net:8000/wiki/moin.cgi/
아무래도 맑은이가 꼭 점쟁이 같이 않아요? 맑은이가 제대로 맞춘겁니다. 속담도 있잖아요. "쥐가 뒷걸음질치다가 소를 잡았다!"라는 웃기지도 않는 속담 --맑은
11.2. 페이지이름바꾸기(Rename Action)가 헛돌기 합니다. ¶
11.3. 페이지이름바꾸기(Rename Action)에서 <역링크>는 바뀌지 않습니다. ¶
현재 페이지이름바꾸기 했을 때 역링크는 함께 변환되지 않습니다. 역링크 부분은 체크 리스트는 있으나, 실제 명령 실행 결과에서는 바뀌지 않았어요. 시도해 본 것은 "두벌식세벌식토론 (->) 두벌식과세벌식토론"으로 이름 바꾸기 한 것입니다. 문서구조조정에 들어가기에 앞서, 보기 쉽도록 마이너 수정을 가 하려던 것이었는데, 여기서 막혀 버렸습니다. --맑은 2005.09.20(화)
역링크 수정동작은 예전노스모크 모인모인과 작동방식이 같지않습니다. 체크리스트를만든 후 역링크 수정을원하는 모든 페이지에 대해 체크박스에 체크를해야 합니다. 예전의 고자동 저유연이던 rename액션을 고자동 고유연 방식으로바꾼것이죠. --고무신
11.4. 페이지이름바꾸기(Rename Action) 결과가 RecentChanges에 곧바로 나타나지 않는데 ... ¶
페이지이름바꾸기 결과가 RecentChanges에 보기 좋게 나타나는군요. 제일 불안했던 부분 중에 하나였었는데 대안이 마련되어 정말 다행스럽고, 기쁘고, 고맙습니다. 그런데 변경되었다는 표시가 곧바로 나타나지 않고, 시스템에 그 다음의 수정을 가했을 때 비로소 나타나도록 된 것인지요? 방금의 경험은 그런 것이 아닌가 추측하게 합니다. 왜 그런 것이며, 곧바로 나타나게 할 수는 없는 건지요? --맑은 2005.09.20(화)
--11.5. 페이지이름바꾸기(Rename Action) : 페이지 내용의 마지막 수정자가 페이지를 지운 것처럼 보여지고 있습니다. ¶
페이지 <이름>을 고친, 맑은이의 발자국에는 "그 페이지를 마지막으로 건드린 사람이며 무슨 짓을 했는지"까지 분명하게 명시되도록 새롭게 만들어져 있어서, 한편으로 안도의 한숨을 깊게 들이 쉬고 뒤를 한 번 돌아다 보았습니다. 그런데, 이 거이 어인 일이랍니까? 페이지 <내용>을 고친, 감기군님의 발자국에 마치 감기군님이 페이지를 지운 것처럼 보이고 있습니다. 오해를 유발하도록 안개가 자욱하게 끼어 버린 셈이네요.
이대로는 안 되고, 고쳐야 한다"는 것에는 모두가 동의 않겠는가, 넘겨 짚어 봅니다. 그럼 어떻게 고쳐야 하나를 생각해 보아야겠지요?
(멍한중) --맑은 2005.09.21(수)
11.7. BadContent ¶
이런게있으면좋겠다에 BadContent가 있다고 저장이 안 됐었습니다. 여기에서 지워진 부분이 문제의 글입니다. --PuzzletChung
여기에서 지워진 부분이 문제의 글입니다. --PuzzletChunglycos.de가 BadContent에 등록되어있더군요. 그래서 뺐습니다.
12. 아이콘 문제 ¶
지금 기존 문법 중에 도 안 통하고, 막대줄의 랜더링(?)을 막아주는 기능도 모르겠고, 그래서 어거지로 해결된 문제의 막대는 *로 바꾸어서 TOC에 나타나지 않도록 하려고 제안했던 것인데, 별로 쓸만한 방법은 아닌 것 같아요. 왜냐하면 최종적으로는 TOC에 모든 해결된 문제들이 나타나야 할 것이므로, *로 해서 안보이게 하더라도, 되돌려 놓는 수정 작업이 또 들어가게 마련이거든요. 좋은 방법이 있을까요? (쏘리) --맑은
도 안 통하고, 막대줄의 랜더링(?)을 막아주는 기능도 모르겠고, 그래서 어거지로 해결된 문제의 막대는 *로 바꾸어서 TOC에 나타나지 않도록 하려고 제안했던 것인데, 별로 쓸만한 방법은 아닌 것 같아요. 왜냐하면 최종적으로는 TOC에 모든 해결된 문제들이 나타나야 할 것이므로, *로 해서 안보이게 하더라도, 되돌려 놓는 수정 작업이 또 들어가게 마련이거든요. 좋은 방법이 있을까요? (쏘리) --맑은 문법 추가는 PuzzletChung님이 해결법을 알고계십니다. 모니위키에 있는 
문법으로 얼추 비슷한 효과를 볼 수 있지 않을까요? 그리고 TOC에서 깊이를 지정할 수 있는 옵션이 모인모인에는 있는데 모니위키에서는 없었습니다. 깊이를 지정하는 옵션을 쓸 수 있도록 고쳐야겠네요 --고무신
이것을 쓰는 것이 어떨까요. --PuzzletChung(./)는 모인모인에 원래 있는 문법입니다. 기존 사용자를 위해서 를 추가해야 하지 않을까요? wikismiley.php를 nsmksmiley.php라는 이름으로 복사한 후에 이것을 고치고, $smiley="nsmksmiley";라고 하면 소스 수정을 버전 올릴때마다 반영해야 하는 불편함도 없습니다. --고무신
를 추가해야 하지 않을까요? wikismiley.php를 nsmksmiley.php라는 이름으로 복사한 후에 이것을 고치고, $smiley="nsmksmiley";라고 하면 소스 수정을 버전 올릴때마다 반영해야 하는 불편함도 없습니다. --고무신 문법을 모니위키에서 기본으로 쓸 수 있게 넣어두겠습니다. (cvs 09/08 반영)