Re^2: console editor

maybe the basic things of what I'd like to do would work with vim.
However, I believe the more advanced features I'd love to have would become nasty hacks.

Basically I'm looking for a possibility to store my passwords on my usb stick.
I'm thinking of things like e.g. some sort of obfuscation by adding to all numbers in the passwords another number - someone who is looking over my shoulders would not see the real password.

Yes, I know there are apps like pwsafe, but maybe I'm addicted to programming....

>>But I doubt using curses would be easier than writing my own ui library
>I seriously doubt that, it's more effort than you think.
>Curses seems to be the best, albeit low level solution.

I could imagine to use curses/pdcurses for the basic things like interfacing with the keyboard/drawing chars to the screen.

Everything beyond this like drawing borders,... seems to me not too much work if there would be a well defined module structure.

There's also the point, that my odyssey through the net surprisingly didn't reveal a useful ui toolkit besides the ones I mentioned in the OP.
So console ui modules in perl could be possibly of some use..

/btw., moritz, your pictures of scotland are really great!

Comment on Re^2: console editor

Replies are listed 'Best First'.
Re^3: console editor by mr_mischief (Monsignor) on Sep 02, 2007 at 22:34 UTC
I'm a vim user. I would think you probably can do the same thing from emacs, so I'll start by suggesting one relatively simple method as a solution for both. Corrections on the emacs part welcome. I've also looked at lots of other editors over the years, as I find editors to be a peculiarly interesting issue. I'll end with some other suggestions for powerful text editors in case the many versions of vi descendants and emacs derivatives don't meet your needs. It's quite possible to filter your file through another program and have the new, filtered data come up into your editor buffer. It's also possible to have editor macros which, for example, would load a file and run a filter on it to start working with it. You could also have a macro that filters a buffer to encode it then saves it. Learning how to do this in a general-purpose text editor could give you a much bigger return on time than implementing a special-purpose text editor. For instance in vim, I could have my buffer filtered through a program written in Perl, through GPG, or through pretty much any other program. It's nice that vim runs just about anywhere other than smaller embedded systems. As was previously mentioned, you can embed Perl into vim or another vi-family editor as well, and then there's vimscript (which may or may not be flexible enough to do what you want). I think vile (another descendant of plain vi) has a Perl extension option already available. There's also MzVim, which is a version of vim with MZScheme embedded as a scripting language. Most versions of emacs can probably do the same sort of thing with external filter programs. Lots of them also have Lisp of some sort embedded (and a few are largely implemented in their own extension language). I think I've seen other languages embedded into certain versions of emacs as well. JEmacs, for example, accepts extension in Emacs Lisp but also in Scheme (and is written in Java). If you get a version of emacs with a language built in that runs in all of your desired environments, you could probably write everything you need internal to emacs as extension functions or whatever emacs users call them. Don't overlook Emacs::Lisp along with PerlMacs or EPL to get GNU Emacs or XEmacs extended via Perl, either. In general, there are other editors that can probably do what you want, too. Yi is written in Haskell and extensible in Haskell. It has vi, joe, emacs, nano, and other interface modes. The editor known as jed has SLang embedded in it, is available on many platforms, and has support for many key binding sets (including Wordstar and Borland Turbo Editor for the old DOS hands!). AEditor is written in and extensible in Ruby. Any of these, given the time to learn enough of the embedded language, could probably do what you want without reinventing the text editor wheel. The time spent to tackle this problem in terms of any of these solutions could give you a good familiarity with how to tackle many more problems similarly. That's probably better in the long run than having a dozen special-purpose text editors with a dozen different key bindings lying around your system. If you do choose to implement this by implementing a new text editor, please make it a text editor framework that can have pluggable Perl modules and such, and consider sharing it on CPAN. That way, you can perhaps cut down on how many times this wheel gets reinvented in Perl. A Perl-extensible general-purpose text editor written in Perl could be quite fruitful I suppose.	[reply]

Replies are listed 'Best First'.

Re^3: console editor
by mr_mischief (Monsignor) on Sep 02, 2007 at 22:34 UTC

It's quite possible to filter your file through another program and have the new, filtered data come up into your editor buffer. It's also possible to have editor macros which, for example, would load a file and run a filter on it to start working with it. You could also have a macro that filters a buffer to encode it then saves it. Learning how to do this in a general-purpose text editor could give you a much bigger return on time than implementing a special-purpose text editor.

For instance in vim, I could have my buffer filtered through a program written in Perl, through GPG, or through pretty much any other program. It's nice that vim runs just about anywhere other than smaller embedded systems. As was previously mentioned, you can embed Perl into vim or another vi-family editor as well, and then there's vimscript (which may or may not be flexible enough to do what you want). I think vile (another descendant of plain vi) has a Perl extension option already available. There's also MzVim, which is a version of vim with MZScheme embedded as a scripting language.

Most versions of emacs can probably do the same sort of thing with external filter programs. Lots of them also have Lisp of some sort embedded (and a few are largely implemented in their own extension language). I think I've seen other languages embedded into certain versions of emacs as well. JEmacs, for example, accepts extension in Emacs Lisp but also in Scheme (and is written in Java). If you get a version of emacs with a language built in that runs in all of your desired environments, you could probably write everything you need internal to emacs as extension functions or whatever emacs users call them. Don't overlook Emacs::Lisp along with PerlMacs or EPL to get GNU Emacs or XEmacs extended via Perl, either.

In general, there are other editors that can probably do what you want, too. Yi is written in Haskell and extensible in Haskell. It has vi, joe, emacs, nano, and other interface modes. The editor known as jed has SLang embedded in it, is available on many platforms, and has support for many key binding sets (including Wordstar and Borland Turbo Editor for the old DOS hands!). AEditor is written in and extensible in Ruby.

Any of these, given the time to learn enough of the embedded language, could probably do what you want without reinventing the text editor wheel. The time spent to tackle this problem in terms of any of these solutions could give you a good familiarity with how to tackle many more problems similarly. That's probably better in the long run than having a dozen special-purpose text editors with a dozen different key bindings lying around your system.

If you do choose to implement this by implementing a new text editor, please make it a text editor framework that can have pluggable Perl modules and such, and consider sharing it on CPAN. That way, you can perhaps cut down on how many times this wheel gets reinvented in Perl. A Perl-extensible general-purpose text editor written in Perl could be quite fruitful I suppose.

[reply]