[Fwd: Fwd: [dev] Suckless word processing solution?]

From: pancake <pancake_AT_youterm.com>
Date: Tue, 06 Oct 2009 10:43:53 +0200

Sorry for the fwd:fwd..i had some mail issues

attached mail follows:

Begin forwarded message:

> From: pancake <pancake_AT_youterm.com>
> Date: October 5, 2009 3:32:53 PM GMT+02:00
> To: pancake_AT_youterm.com
> Subject: Fwd: [dev] Suckless word processing solution?

> Begin forwarded message:
>> From: pancake <pancake_AT_youterm.com>
>> Date: October 5, 2009 3:04:00 PM GMT+02:00
>> To: dev mail list <dev_AT_suckless.org>
>> Subject: Re: [dev] Suckless word processing solution?
>> I know that it may sound like reinventing the wheel.. Because it is
>> in fact the wheel reinvented.
>> Vi is the visual ed, but I have never seen any implementation using
>> ed. They just embed it inside the 'GUI' .
>> I think that having all the editing engine implemented in ed is
>> simple to wrap it into a GUI based on X11 or ncurses.
>> Vim supports launching apps to filter text, but it is not the main
>> way to work. Because is more optimal and easy to port to other os
>> like dos or w32.
>> Syntax highlighting is something that can be implemented in a
>> filter program. The same for indent, line numbering, text
>> alignment, etc..
>> I love vim, but I feel that most of the capabilities it supports
>> are embedded in the editor instead of using a unixlike design based
>> on pipes and filters.
>> Autocompletion, ctags, searchs,,.. Can be implemented outside the
>> GUI without much pain.
>> We just need a GUI that supports X11, ncurses, sdl or OpenGL that
>> allows to bind some keybindings to run commands at Ed level or
>> change the filters for example.
>> The main problem in this application is to find the good
>> simplification of the design to allow good flexibility, performance.
>> Yep, it's the wheel problem again, but I'm just trying to give some
>> spots on things that have been already thinked probably in the past.
>> Acme from plan9 is an interesting approach, but it is unusable and
>> inproductive if you don't want or have a mouse with 3 buttons. My
>> keyboard has at least 105 keys and there are some of them that are
>> still with no use.
>> I understand that having a pointer device as a selector input
>> hugely simplifies the code, but at least for me is not a solution
>> for eficient text editing.
>> It's like when people from notepad.exe discovers the magic of hjkl.
>> Efficient text ediing requires some training. And we have to find
>> an intermediate point between code complexity and user interface.
>> Any proposal?
>> On Oct 4, 2009, at 10:46 PM, Robert C Corsaro
>> <rcorsaro_AT_optaros.com> wrote:
>>> Jessta wrote:
>>>> On 04/10/2009, markus schnalke <meillo_AT_marmaro.de> wrote:
>>>>> [2009-10-01 13:51] pancake <pancake_AT_youterm.com>
>>>>>> * ved (visual mode for ed..like vim, but using ed, indent,
>>>>>> etc.. that
>>>>>> is
>>>>>> reimplement the basics of visual text editor using ed and other
>>>>>> scripts as backend)
>>>>> vi is the visual mode for ed (for ex, to be exact). It can also
>>>>> invoke
>>>>> arbitrary external programs.
>>>>> Why reinvent the wheel?
>>>> That cliche really annoys me. The wheel has been constantly
>>>> reinvented
>>>> for thousands of years and there are currently companies spending
>>>> millions of dollar researching how they can reinvent it again.
>>>> vi is a terrifying beast, I imagine pancake was thinking of making
>>>> something less terrifying.
>>> I imagine that any editor that is optimized to make editing
>>> extremely quick and efficient will be a terrifying beast. I
>>> respect the opinion that vi sucks, but I don't respect that
>>> opinion that text editing should be so simple to learn that my
>>> grandmother could do it. I edit text 8+ hours a day so I don't
>>> mind spending some time learning to be more efficient.
Received on Tue Oct 06 2009 - 08:43:53 UTC

This archive was generated by hypermail 2.2.0 : Tue Oct 06 2009 - 08:48:02 UTC