모인모인과 사용방식이 같다고, 설명서 제대로 안만들고 멀뚱멀뚱 하고 있습니다 ^^;; --고무신 잘 알았습니다. --맑은

네 간단한 수정은 아닙니다. 보기/고치기 명령이 동시에 못오도록 되어있거든요. ^^;; MoinMoin동작방식과 꼭같습니다. 상단 아이콘은 맘대로 고칠 수 있지만요. --고무신

명언을 보려고 안갱(DIFF)를 껴 보면 "옛 버전이 없습니다"(또 점이 없어)라고 나옵니다. "없긴 왜 없어!" 왕짜증을 내면서 안경을 벗어 던지고, 페이지 박물관으로 갔습니다. 페이지 역사(;) 누구의말일까요?아는사람은알지요?)를 보면, 분명히 옛 버전이 달랑 하나' 있습니다. 만든 이는 PuzzletChung! 만든 날은 2005년 8월 25일 새벽 5시경! 그러니까 지금은 쓰기만 못하고 있는 게 아니라 읽지도 못한다는 이야기 같은 걸요.

어? 방금 봤는데, 그나이땐어떤일을, 이 페이지에 페이지 역사가 만들어지고 있는 바로 이 순간에도! 명언에는 역사를 쓸 수도 읽을 수도 없습니다. 그러니까 지금 이 순간에도, 파일의 속성들이 가지런하지 않고 들쭉 날쭉 하다고 보아야 하는 거지요?

--맑은

이건 모니위키 구현문제이자 버그로 보신 것 같은데, 현재 페이지가 없으면 지워진 것이고, 쓰레기통을 누르면 현재 페이지가 없으므로 보여줄 diff가 없다고 하는게 맞는것 아닐까요? 이것은 마치 diff명령이 두개의 인자를 필요로 하는것과 같은 원리입니다. diff명령은 원래 페이지와 비교 대상의 두개의 페이지가 있어야합니다. 하나가 없으면 diff는 실행 안되죠. 아이콘을 누르면 아예 info로 바로 가게 할 수도 있겠고요. --고무신

으이그, 버그라고 한 게 아니고요, 옛버전이 있는데 왜 없다고 하느냐고 물은 거지요. 고무신님의 설명을 들으니 왜 그렇게 나오는지는 이해가 되었어요. 단지, 있는데 없다고 하는 이유를 알아들었다는 것이지요. 그러니까, 고무신님은 "MoniWiki의 DIFF명령은 이렇게 돌아 갑니다."라고 한 거고 맑은이는 "아, 그래서 그랬었구나" 하며 상황을 이해하고 다음으로 넘어 갑니다. (아참, 맑은이는 버그라고 단정하는 실수를 할지언정 버그라고 단정하지는 않길 바라는 동물입니다. 따라서 고무신님의 오해가 있는 듯하여 해명하려 합니다. 또 아참, 그보다 먼저, 맑은이는 심리학분류를 절대로 지우지 않았음도 강조해 두고요.)

"이것이 버그인가 정책인가" 하는 것은 MoniWiki 자체를 직접적으로 "평가하려 할 때"와 "배우려 할 때"의 물음이 되어야겠지요. 하지만, 지금하는 것은 삼차노스모크이전/문제해결이라는 절차입니다. 따라서 엔진이 바뀐 상태가 먼저 보이는 것이 아니라, 기존에 손에 익었던 기능들이 그대로가 아닌 것이 먼저 보이는 것이지요. 이런 시각의 차이가 있을 수 있다는 것은 충분히 이해하시지요?

끄트머리 사용자로서의 노스모크OnSider들에게는 '버그'가 보이는 것이 아니라 '문제'가 보일 뿐입니다. "저렇게 보이던 것이 이렇게 보입니다." 다르잖아요. 달라졌잖아요. 다르다고요. 음, 노스모크모인모인에서는 "옛버전이 하나만 있는 상태에서 페이지가 지워졌을 때에도 저렇게" 보여줬던 것으로 기억합니다. 그랬기 때문에 그렇게 만들어달라고 때를 쓰고자 함이 아니라, 적어도 "어느 방향이 나은 것인지"에 대한 토의는 할 수 있잖아요?! 토의를 하려면 문제를 끄집어 내 놓아야 할테지요? 지금과 같이 말입니다. 아무튼,

저렇게와 이렇게, 그 다름을, 맑은이는 해결해야 할 문제로 본 것이고, 고무신님에겐 그것이 문제로 보이지 않는 것이었지요. 어쩌면 그건 당연한 일일지도 모릅니다. 그것이 문제일리가 없는 고무신님은 자연스럽게 맑은이가 MoniWiki의 버그를 지적하는 것으로 여길 수 밖에 없었겠지요?! 그러나 아닙니다.

봉착한 문제를 해결하다보니 그 중에는 우연히 MoniWiki의 버그로 판명된 것들도 있고 정책,디자인 등등의 이유들도 있었던 것이었지요. 혹시라도 오해가 있었다면 화끈하게 풀렸으면 좋겠구만요.

이제 남은 문제는 "이 문제를 어떻게 할 것인가?" 입니다. (휴우~)

--맑은

다시 저렇게 만든다.

그냥 이렇게 쓴다.

DIFF아이콘을 누르면 아예 info로 바로 가게 한다.

또 다른 의견들...

버그입니다. 버그 맞고요, 제가 의도한 것은 info를 보여주는 것이었는데 그렇게 안돌아가고 있었습니다. 게다가 저는 위에서 말했던것처럼 diff라는 유틸리티가 그렇게 동작하니 그렇게 보여도 그게 이상하지 않은것으로 여기고 버그라는 생각을 전혀 못한것이죠 ^^;;

우선, 아이콘이 예전의 deleted가 아니고 쓰레기통입니다. 사용자가 쓰레기통을 누르는것은 diff를 원하는 것이 아니겠고 그 쓰레기통에 무엇이 있을지 보는것이리라 생각했습니다. 이것은 new아이콘을 눌렀을때 info를 보여주는 것과 같은 이유입니다. 그리고 예전 노스모크모인모인에서는 아이콘이 deleted였으므로 그 아이콘을 누르면 어떻게 보여줘야 하는지는 분명하지 않았습니다. 일단 눌러보고, 아... 지워져서 뻘겋게 다 나오는구나 라고 생각하지 역시 이게 diff의 결과인지 아닌지는 상관하지 않았겠죠.
일단 info로 생각하는것이 맞다고 생각하므로 info로 고쳐놓겠습니다. 혹 예전 노스모크 모인모인과 호환을 생각하는 분이 계시다면 따로 옵션을 만들면 되겠죠. --고무신

이젠 '하얀아이'로 바꿔야 하는게 아닌가 모르겠네요.-- CafeNoir

아이콘 테마를 쓰면 예전 아이콘을 쓸 수도 있습니다. imgs/nsmk/에 같은 이름의 아이콘을 넣은 후에 $iconset='nsmk';라고 하면되죠. 단, 모두 png파일이어야 합니다. --고무신

현재 대로라야, 진짜 파란아이 아닌가요? 예전이 하얀아이였습니다. --맑은

인코딩을 변환했습니다. --PuzzletChung

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
  > 공지사항
  > 노스모크운영비현황/모인모인시대
  > 바투타
  > 삼차노스모크이전/문제해결
  > 우롱차
  > 위키위키모음
  

  바뀐 이름, 아햏햏,아햏햏토론, 사랑하면알게되고알게되면보이나니
  숫자가 안맞아서 살펴보니 CypherGnuSinn 페이지가 누락되었네요. --고무신
  
  

"파일이름이 너무 길어서 편집할 수가 없어!"

모니위키 1.0.9.2 버전을 깔은 worry입니다. 어제 3차 노스모크에 애플 타이거(OS 10.4) 사파리로 접속해봤는데, 노스모크는 정상적으로 인코딩이 되는데 제 모니위키는 글씨가 보기항목에서 어느 코딩으로해도 깨집니다 ;;. 버전업에 따라 코딩이 달라진 걸까요? 윈도 XP sp2에서 익스플로러, 불여우로 접속하는 것은 _bc_bd로 주소가 뜨고 다 정상적으로 보입니다. 근데 문제는... 바로 윗부분이 지적해주신 인터위키 접속시 글씨가 깨집니다. -_-;;;; 제 생각엔 제 쪽의 코딩을 바꿔야 잘 해결될 문제로 보입니다. 노스모크 모니위키의 버전명과 설치시 달라진 부분을 알 수 있는 페이지를 만들어보면 어떨까요? 일단 정리하자면 이렇게 됩니다. 제 모니위키 토란밭을 1.1 릴리스 버전으로 업그레이드해보고 다시 쓰겠습니다. - worry

.	OS 타이거 사파리	XP sp2 익스플로러	XP sp2 불여우
토란밭 (모니위키 1.0.9.2)	유니코드로 글씨정상 (주소창한글이름)	글씨정상	글씨정상
노스모크 3차 (모니위키 버전?)	유니코드로 글씨정상(주소창한글이름)	글씨정상	글씨정상

merge를 눌러보세요. --고무신

위키위키가 불안한 시스템이라는 건 그런 의미로 받아 들이지는 않았습니다. 저장하라고 했는데 지워버렸다거나 하는, 기능적으로 불안한 시스템은 아니잖아요. 저장하랬으면 저장하는 것이고, merge하랬으면 머지하는 것이고! 여기까지는 맞지요. 이 흐름을 끊었으면 좋겠다는 게 맑은이의 의견이었습니다. 아무튼 여기서 분명한 것은 "merge 직후에는 반드시 다시 편집해야 한다는 것"입니다. 글이 온전치 않기 때문입니다. 따라서 <저장>단추만 주지 않는다면, 지금 이대로라도, 차이가 나는 부분에 대한 DIFF 메세지를 보여준 것까지라도, 사용자는 얼마든지 고맙게 유용하게 쓸 수가 있습니다.

프로그램이 어떤 구체적인 기능을 사용자에게 주었을 때, 사용자는 그 기능을 믿고 씁니다. 거기에서 실패 가능성을 염두에 두지는 않고 믿고 쓴다는 말입니다. 쓰다고 실패하는 경우가 생기기도 하지만 그것은 뻔히 아는 상황은 아니지요. 아무튼 어떤 작업이 실패를 하더라도, 실패의 흐름 속에서 데이타에 손상이 가해질 수 있음을 고려하지 않습니다. 만약 어떤 작업이 실패했다면 그 트랜잭션은 끝을 내야지 연속하게 되면 문제가 발생할 소지가 크다고 생각합니다. 아는 사람은 쓰던가 안쓰던가 하겠지만, 처음 접하는 사람이 실패한 내용을 그대로 저장해 버린다면 일이 너무 커져 버릴 수가 있는데 이건 사용자의 잘못인가요?

맑은이가 merge를 처음 만났을 때 이런 행동을 보였답니다. 편집 -> 저장 -> 충돌! -> merge -> 저장 이 게 처음 접하는 사람들의 일반적인 흐름 아닐까요? (크흐,일반화오류다!) 그랬더니 저장된 내용이 엉터리가 되어 버린 거에요. 설마, 뭔가 잘못되었다면 문제상황을 알려줬겠지, 그랬으면 더 이상 진행하지 않았을텐데. 페이지의 글은 여기 저기가 중복되어 있고 내가 쓰지 않은 글자까지 마구 들어가 있고. 처음엔 누군가가 같이 편집하고 있는 줄 알고 속으로 그랬죠. "당신, 누구요! 왜 남의 글을 쓰는 도중에 건드리냐!" 그런 다음 내가 쓰지 않은 부분, 나의 동작과는 전혀 관련이 없다고 생각되는 부분을, 지워야 하나 말아야 하나."까지 한참을 고민했습니다. "그래! 지우기로 하자, 지금은 한가지만 생각해." 이러면서 다시 편집창을 열어 손으로 일일이 다 지웠다는 것 아닙니까. 우습죠? 맑은이는 얼마나 심각했다고요. 맑은이가 [맑은] 손으로 분명하게 <merge 단추>를 눌렀지만, merge가 그런 것이라고, 상상이나 했겠어요? 사용자는 프로그래머가 만들어준 기능을 믿고 씁니다. 이 문제는 정말이지 한 번 더 생각해 봐 주신다면 고맙겠어요. --맑은

양손항해 페이지를 봐도 문제가 해결된 것 같지 않습니다. 페이지 제일 끝으로 갈 때 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를 누르는 것으로도 가능합니다. --고무신

<ESC>는 다른 기능으로 이미 쓰고 있는 거라서, 무진장 헷갈릴 것 같아요. 수정중이던 텍스트를 꺼내주는 키로 쓰로 있는 걸요. 일단 맑은이는 "alt-x,alt-s"에 적응해 보도록 하겠습니다. 표준과 연관된 정책문제라면 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에서 테스트해보세요~ --고무신

지금도 되는 거에요? IE로 지금 들어가 보니 안되거든요? 그렇다고 노스모크의 특성상 오페라로 바꾸기는 뭐하고. 뭔가 골똘히 생각중... 그러면 "하나의 단축키로 두 마리 토끼 잡기는 포기해야 하는 건가요?" --맑은 2005.09.01(목)

테스트를 너무 열심히 해서 그런지 오른쪽 팔에 근육통이 왔습니다. 재해다,재해. 책임져욧! 양손항해 제대로 할 수 있게 해 달란 말에요. 메롱이라고라?엥그리는어케하는겨? x-( (씩씩) (먼가할얘기가있었는데...음...머드라...히드라...페드라...) 아! --맑은

양손항해에서 밝혀두었지만, 예전 노스모크에서 쓰던 alt-x는 InternetExplorer에서밖에 쓸 수 없는 기능이었습니다. 그러므로 양손항해에 대한 부분은 예전부터 잠재적으로 있었던 문제점이었습니다. 오른팔에 근육통이 오셨다는건 마우스를 넘 많이 쓰셨다는 말씀이신거 같은데 ㅋㅋ 암튼 테스트 많이 해주세요 =3=3=33 --고무신

도망가는 건 여전 하십니다. --맑은

조금 찾아보니 alt-z는 페이지의 맨 밑으로 가거나 Access key 목록을 보여주는 기능을 하는군요.

![연결] 문법으로 대치할 수 있습니다.

NoSmoke 모인모인시대 : http://puzzlet.dnip.net:8000/ns/moin.cgi/

LovolNet 모인모인시대 : http://puzzlet.dnip.net:8000/wiki/moin.cgi/

아무래도 맑은이가 꼭 점쟁이 같이 않아요? 맑은이가 제대로 맞춘겁니다. 속담도 있잖아요. "쥐가 뒷걸음질치다가 소를 잡았다!"라는 웃기지도 않는 속담 --맑은

rename은 MoniWiki와 노스모크모인모인이 작동하는 방식이 다릅니다. 제가 테스트해보니 잘 되는 것으로 보아서는, show only의 체크를 해제하지 않고 작동시켜서 그런것일 가능성이 높습니다. --고무신

기본옵션이 노스모크모인모인과 달랐던 것이고, MoniWiki의 기본옵션(show only)의 처리결과에 대해 맑은이가 "헛돌기"한 것으로 오해를 했구만요. 다시 해 보니까 잘 변경되었습니다. 기능상의 이상은 없네요. "한 번은 오해를 해도, 백 번은 잘 쓰리라!" --맑은

역링크 수정동작은 예전노스모크 모인모인과 작동방식이 같지않습니다. 체크리스트를만든 후 역링크 수정을원하는 모든 페이지에 대해 체크박스에 체크를해야 합니다. 예전의 고자동 저유연이던 rename액션을 고자동 고유연 방식으로바꾼것이죠. --고무신

지금은 또 곧바로 나타나는데, 음, 어케 된 거래요? (바보가되는느낌이 몰려오는) --맑은

ㅋㅋ 그럴리가요 InternetExplorer가 맑은님을 속인거예요 --고무신

잉, 밉다. --맑은

예전에도 있던 문제점입니다. 그나마 지금은 rename액션 기록이 남지요. 하지만 맑은님이 제안하셨으므로 최소한의 구현비용으로 느리지 않으면서도 지적하신 문제점이 해결되는 방안을 생각해 보겠습니다. 현재로써 생각나는 방법은, 이름 바꾼 기록과 지운 기록 두개를 모두 남기는 것입니다. 그러면 지적하신 문제점은 발생하지 않습니다. --고무신

그러게, 애시당초 말입니다, 그 페이지를 마지막으로 핸들링한 사람은 맑은이였으므로, 페이지이름고치기하여 발생된 블랙리스트이므로, 당근 맑은이가 올려져야 되지 않컸써요? --맑은2단

lycos.de가 BadContent에 등록되어있더군요. 그래서 뺐습니다.

이것을 쓰는 것이 어떨까요. --PuzzletChung