月別アーカイブ: 2009年2月

Ctrl+Space

スニペットを使わず嫌いなのはもったいないと思って試してみる。
ようするに何か短いキーワードを打ち込んで Tab キーを叩くと残りとかが保管される機能。
空のファイルを *.py の拡張子で保存して py とだけ打って Tab を叩く。

sn_py

それだけでココまで勝手に書き込んでくれる、みたいな機能である。

Windows では Tab は単なるインデントのイメージがあるけど UNIX は違う。
同様な機能が色々なアプリに搭載されているが何故こんな文化が UNIX にはあるのだ?
と思っていたけど端末(bash)でよく解った。

bash 入門

$ cd y

たとえば上記みたいに打ち込んで Tab キーを叩く。
現在のディレクトリに y で始まるディレクトリが y901x しかない。
なんて場合は $ cd y901x まで完全に保管される。
複数ある場合は 2 回 Tab を叩けば候補が表示される。

知らなかった…まだまだ知らないで損しているコトは多い。
「↑」キーを叩くと直前に打ち込んだコマンドが流し込まれるとかは知っていたけど。
Python とかをやっていると実効確認とかでよくやるんだなコレ。

とにかく。
シェル自体にそんな文化があるのでは GUI になっても変わらないわな。
問題はそのキーワードを覚えておかなければいけないこと。
登録したところでキーワードを忘れてしまっては無意味だ。

しかし何を考えたのか Ctrl+Space を押してみた。

cspace

あれ?こんなことができたんだ、Visual Studio のコード保管と同じキーなんだが。
何故今まで叩いてみようと思わなかったのだろう?まあいいけど。
スニペット保管のみだけど十分だ、少なくともキーワードを覚えておく必要は無い。
これならば使ってみようと考えるわ、秀丸のように使おうと思うから駄目なんだと。

…まだまだ知らないで損しているコトは多い。

またしても INI

次の覚書は意表を付いて inifile8 の Python 化をやる。

コレをやらなきゃ SeeMe を Python で作り直しができないしぃ。
問題は Windows 版をどうするかなんだが、IronPython では .NET で変わらないし。
v4 は C++ で作るしかなさそう、.NET はもう企業のほうしか見ていない。

それに毎回 has_option でキーの確認をするのがバカバカしくなったのでまあ。
以前 C# で書いたのを Python で書き直しなんてことをしているんだが…
面倒なので巨大画像。

cs2py

コードの圧倒的な短さに自分で吹いた!
やっていることはまったく同じなのに。
辞書のリストの辞書のリストを作っているだけなんだが。

しかしコレを解説となると Python の基本を説明になってしまうような…
初心者本でも勧めてヨシとするか(ぉい!

Home キーを 2 回叩け

以前書いたけど私は Python を gEdit でコーディングしている。

Emacs や vi とかに興味を持たないのは私はブラインドタッチができない(マジで)からである。
てゆーか Delphi や Visual Studio を使っていたので Windows 風にしかエディタが使えない人。
Scribes なんかも多機能で悪くないけど何故だか馴染めない。

コード保管がまったく使えないのが最初は気になったが慣れた、今まで楽をしすぎただけだ。
Python ならではのインデントも Tab と Shift+Tab を利用するだけだ、逆に今は括弧がウザい。

でもたった一つだけ不満がある、Home キーで文の先頭に行ってほしいのだ。
Visual Studio で慣れてしまった、gEdit のエディタ部は gtksourceview のはずなのに。

gtksourceview.SourceView

def set_smart_home_end(enable)
なんてメソッドがあるヤン!何故これができないのだろう?
Python コンソールで試してみよう。

view = window.get_active_view()
view.set_smart_home_end(True)

gedit_cons

できるヤン!何故設定が無いのだ?
プラグインでも作るか、と思ったけどもしかしてと思い「設定エディタ」を開く。
メニューに無い人は端末で gconf-editor で。

apps→gedit-2→preferences→editor→smart_home_end

gedit_home

おいおい、設定があるやないの!
下に出る解説をよく見ると…Home キーを 2 回叩いてみる。
知らなかった、わっはっは今まで何を無駄な操作をしていたのだ俺は。

でもこれでは気持ち悪いので BEFORE に変更。
Visual Studio や Bluefish とコレで同じ動作だ。

ついでに書いておこう。
Gnome のエディタ部は全部トリプルクリックで一行選択になります。
すぐに気がつくと思うけど、何かまだ知らないで損していることって多そうだなぁ。

ChangeLog

changelogimg

単純にファイルを作って名前を ChangeLog にしただけのテキスト文書。
それだけで名の知れたエディタなら色分けして表示される、へぇこうなるんだ。
解説不要なほど単純な表記で読みやすいし日本語もコレなら問題無い。

何より書き方が統一されるので誰が書いたとしても理解しやすい。
Python の良さを理解できる人ならそのメリットは解るはず。
面白い文化があるもんだ UNIX の世界は。

こんな面白い文化は開発用途だけではもったいない!
何か他に面白い使い方は無いかな?

“ChangeLog” – Google 検索

同じ事を考える人って多いんだなぁ…

問題はファイル名が限定されるので同一ディレクトリに一つしか置けないこと。
アレの覚書!コレの覚書!としたい場合…やはり使い方が限定されてしまうか。

ソレならブログに投稿してカテゴリやタグを利用したほうが…それも色々あるが。
自分が書いた覚書を検索しなきゃ探せないのって本末転倒だし、よくやるんだこれが。

万能なログ記録方法って無いので用途で使い分けするしかない。
まあ ChangeLog 自体は日記に満たない単純な覚書利用には最適かと思う。

リサイズ処理はなんとかなった

動画のオリジナルサイズを得る

でリサイズはなんとかなったぞと。
コレでイケたのか、なんて遠回りをしたものだ。
でも勉強にはなったのでヨシとしよう。

次はリサイズするためのメニュー作りだ。

PyGTK + Gladeのアプリケーションにおけるハンドラ関数について(後半) – 試験運用中なLinux備忘録

ユーザーデータがやはり Glade からは使えないみたい。
menuitem 毎にハンドラ作成ではコードが美しく無いんだが…
綺麗に書かなきゃ Python じゃないし。
○uby 屋は他人が読みにくいコードを書くのを好(以下略

しかもラジオボタンのグループにすると何故かグループ全部シグナル吐くし…
まだイマイチ理解していないだけだと思うけど、後は明日だ。