Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

console editor

by misc (Friar)
on Sep 02, 2007 at 11:29 UTC ( [id://636594]=perlquestion: print w/replies, xml ) Need Help??

misc has asked for the wisdom of the Perl Monks concerning the following question:

Oh fellow monks!

I'm trying to implement a small editor for encrypted files for my own,
it should be portable (Linux,Win,Dos,..?) and have a console user interface.

I tried Curses::UI first, but it seems hard to me to extend the functionality of e.g. the texteditor
Besides I experienced some bugs in the library and the author/maintainer seems to be unavailable

For sure I could implement something around the limitations,
but that's not the way I like coding.

I've googled around, but so far didn't find something useful, which would be usable from perl

I'm feeling heavily tempted to write my own console ui library..
Implemented in perl, object oriented, will rule the world...
I'd however prefer to use existing code, saving me 5 pounds of coffe, sleep, and some tobacco.

Could perhaps anyone suggest a portable library|module|whatever for a console ui editor, which is also extendable ?

Here's what google told me yet:
  • http://tvision.sourceforge.net/ (CPP)
    This is a port of Turbi Vision(Borland).
    Seems interesting, but it's cpp.
    as far as I know, it's not possible to overwrite virtualfunctions from within perl.?
  • http://www.morphet.org.uk/comp/steph.html (C)
    the author considers this as beta, the last release was 2002
  • Curses, of course
    But I doubt using curses would be easier than writing my own ui library
  • Text::Editor::VIP
    I haven't found out howto use this.
    I guess it's not usable at all and abandoned after I looked into the sources.

Replies are listed 'Best First'.
Re: console editor
by moritz (Cardinal) on Sep 02, 2007 at 12:49 UTC
    I know this isn't what you are looking for, but vim runs on many platforms and can write and edit files in its own encryption format.

    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'd put my 1 next to using $VISUAL or $EDITOR, and just playing tricks on it

      Then you can please both the vim and emacs zealots.

      @_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;

      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!
        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.

Re: console editor
by almut (Canon) on Sep 02, 2007 at 19:57 UTC

    I'd like to throw in another suggestion, S-Lang, which is roughly comparable to curses/ncurses in its abstraction level. The description from its home page probably summarizes it better:

    S-Lang is a multi-platform programmer's library designed to allow a developer to create robust multi-platform software. It provides facilities required by interactive applications such as display/screen management, keyboard input, keymaps, and so on. (...)

    And, as to the support beyond the Unix world (from the INSTALL.pc file):

    The slang library is available for OS/2, MSDOS, and WIN32 (windows 9x/NT) systems. This _includes_ the various GNU environments such as DJGPP, and MINGW32. For CYGWIN, follow the UNIX instructions.

    (Actually, it's not only that, but also a full programming language / interpreter, etc., but the cited part should about fit what you're interested in...)

    One advantage is that it's both stable (been around since the mid-90's) and actively maintained (latest release June 2007).

    A number of well-known programs with a text-based UI make use of it (or optionally may be linked against it, instead of ncurses), like for example mc (Midnight Commander file manager), mutt (mail client), slrn (newsreader), lynx (html browser), and various text editors.

    In principle, there's also a Perl binding for it Term::Slang. Unfortunately, it dates back to the year 2K, and doesn't seem to be maintained any longer. Anyhow, the module is a decent start, and it should be rather straightforward to upgrade/extend for anyone determined (or even addicted to programming, like you :).

    Actually, I just tried building it against the most recent S-lang library v2.1.1. As expected, it did no longer work, but it took me only about half an hour to come up with fixes/workarounds for the fatal errors. There are still 7 compile warnings left that need to be taken care of... but that should be doable as well. (Most incompatibilities were related to changed function names and/or argument lists, in particular with respect to readline functionality). /msg me privately if you want the diffs.

    Anyhow, now it builds, and you (well, I, at the moment :) can run the Perl examples that come with Term::Slang, e.g. draw-bow, which draws a typical text UI dialog box with a message and Yes/No/Cancel buttons and a line-chars frame around it, centered within the terminal.

    That's about 80 lines of Perl code (including the boilerplate), so you'll probably want to abstract away often used functionality in libs (widgets like dialog boxes, etc.).

    (BTW, if you get anything along these lines working properly, please let me know — I'm personally a big fan of text-based user interfaces, and being able to easily create them with Perl would definitely be a plus...)

Re: console editor
by vkon (Curate) on Sep 02, 2007 at 17:36 UTC
    tvision is an interesting idea (thanks for it, I'll put it into my bag of things)

    as for implementing text-based edits, I have 2 other ideas:

    • use vi, its very programmable and could be compiled with perl and even could be stripped down to just one single file for your purposes; I use this way occasionally
    • there exists some thing ctk, curses-based GUI with Tcl, which could be available from Perl with Tcl CPAN module.
      I never tried this, but should work...
      Its not very maintained, but my last attempt to compile it succeeded...
Re: console editor
by Anonymous Monk on Sep 02, 2007 at 12:22 UTC
    as far as I know, it's not possible to overwrite virtualfunctions from within perl.?
    Why not? Gtk2, wxPerl ... do it
      gtk2 is a c-library -?
      Here is an example in cpp pseudo code how I understood coding with tvision:
      class button { // The tvision class public: virtual void buttonclick(){ //Overwrite me ... } ... } class mybutton public Button { // This is my button ... virtual void buttonclick(){ //do something exit(0); } } int main(){ //Initialize the app.. app->mainloop(); }

      TVision is object oriented, and I don't know howto implement the example of the class mybutton in perl in a useful manner.

      I thought already about a wrapper which implements event style hooks.

      Would look something like this:
      --- cpp layer class perlwrapper_button public Button{ virtual void buttonclick(){ if ( !call perl->this_instance->buttonclick() ){ Button::buttonclick(); // Call tvision's buttononclick } } } --- perl module package Button; sub buttonclick{ return 0; } 1; --- The perl code of mybutton: package MyButton; push @ISA, 'Button'; sub buttonclick{ exit(0); } 1;
      I doubt, however, this concept is wise.
Re: console editor
by Anonymous Monk on Sep 02, 2007 at 11:48 UTC
    secure pico?
      In my revived quest to write components of text-based adventure games in Perl, I ran across this very problem several weeks ago. I tried a number of slang/curses-based wrapper solutions, but all of them gave me some sort of problem. So I wrote a fairly useful UI bit called HexedUI. I've yet to document it or put it on CPAN, but feel free to use it if you can: assilem.org/breegrl/trunk/dean/pui If you have any questions about it, let me know. For the editor, I just delegated to vim. Lazy! One major tip if you do try to do your own low-level thing in curses. Use pads to represent all of the text entry and then use a window to select/scroll. See Hexed::Map or Hexed::Term for an example of this. I also implemented a limited readline-like bit that works with curses since whipping out Term::ReadLine in the middle of curses didn't work. Slang also looked great, but had pitiful high-level documentation, let alone perl-specific. Good luck.
Re: console editor
by perlhaq (Scribe) on Sep 04, 2007 at 01:30 UTC
    I'm interested in hearing more about those Curses::UI bugs you found... I have lately also been looking for a good console UI library, and it was the best I came upon (at least at a higher level than plain old Curses or Term::Cap). Curses::UI is also pretty similar to Tk in its usage, which is a plus for me.

    For the console text editor you seek, I was going to suggest vim (but others have already), so instead I'll suggest another good editor that isn't at all like vim, but has many wonderful features: http://www.triptico.com/software/mp.html

      I didn't know this text editor..
      Thanks for your hint, I'll have to try it, although I'm used to vim.

      About my problems with Curses::UI
      I wasn't able to clear keybindings like documented in Curses::UI::Widget.
      Instead of e.g., as documented,
      $w->set_binding( \&myfunc, "\cF" ); $w->clear_binding( \&myfunc );
      you'll have to call  $w->clear_binding( '__routine_'.\&myfunc ); In order to clear the binding to myfunc.

      I had to look into the sources to figure this out, and I'd consider this a bug.. It should be at least documented in the pod.

      I've mailed the maintainer, but didn't get an answer yet.

      Next problem I had: the texteditor isn't searchable.
      I tried to set some bindings to the according search functions,
      but ended in a mess.
      This time I wasn't able to figure out howto make the texteditor searchable within some hours, I gave up.

      I'd like to say that Curses::UI are great modules as long as you don't want something too complex.

      I personally also hate to do workarounds (which drives me crazy if I've to code some javascript..),
      so I concluded that I'd be better with writing my own ui than using Curses::UI.

      It's not the way I have fun, and I'd also like to say you'll end up in a mess.
      Furthermore I believe such workarounds would become too dependent on the internals of Curses::UI. If anything changes in these modules, the workarounds could easily break.

      Update: My feelings about getting into trouble with Curses::UI have been confirmed.
      I just found this node: Re: text mode screen-oriented application development]
      To quote Withigo: Debugging little quirks in Curses::UI which required custom overrides with Curses code was an especially painful.
      more bugs in Curses, lots not portable

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://636594]
Approved by almut
Front-paged by Courage
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (7)
As of 2024-03-29 13:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found