UVviewsoft forums

back burner? it will be seen by me - but little later.

>This observation brings up an interesting design question: how much (and what parts) of a text editor should be written in something like C or Pascal and what should be done in a higher-level script language? There's an editor around (see https://foicica.com/textadept/ ) which has Scintilla as its editor component but virtually everything else is done in Lua.

it depends on author. RJ TextEd author wants ALMOST ALL as low-level Pascal code.

Alexey wrote:

>This observation brings up an interesting design question: how much (and what parts) of a text editor should be written in something like C or Pascal and what should be done in a higher-level script language? There's an editor around (see https://foicica.com/textadept/ ) which has Scintilla as its editor component but virtually everything else is done in Lua.

it depends on author. RJ TextEd author wants ALMOST ALL as low-level Pascal code.

Wellllllll... talk about personal preferences of programmers! There are some who think that assembly language is best Or how about those who skip even assembler and write their hexadecimal stuff directly into memory

OK, seriously. I've done all these languages since 1977 (6502 and Z80 assembler anyone?) and there's not a shred of doubt in my mind that there's very little reason for assembler/compiled low-level languages other than performance critical stuff or direct hardware access. I fully agree that some things have to be written in low-level... but OTOH I am convinced that the list is much smaller than many programmers assume. Witness Knuth's famous statement:

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming. [my italics]

Having said that, Python as a high-level language is not playing in the same performance league as, say, LuaJIT. Its JIT compiler is normally at least very speedy and often phenomenally fast... if I were to write an editor today (fat chance ) I'd certainly look into LuaJIT for the complete UI and all the interfacing to the editing core. Even large part of the core can be written in a high-level language.

tmsg wrote:Thanks a lot for that, I am really using incremental search a lot.

You are welcome to post any issues/ideas about FiL (FindInLines) here or in github page of Cud (better).

> talk about personal preferences of programmers! There are some who think that assembly language is best Or how about those who skip even assembler and write their hexadecimal stuff directly into memory

yes, personal ones. my personal ones are Pascal coding. i know it since TurboPas 7.0. if I knew Lua i would made editor in Lua!! but I don't use Lua. if I was making editor in Lua then yes, i could made almost all in lua - even the rendering engine, coz Lua speed is ok and rendering in lua could be ok and fast - using opengl for example. "Lite" editor is made in lua. it's fast! it don't have folding support, it don't have even 10 lexers, it don't have this, it don't have this and this, but it's fast, faster than Cud..

kvichans wrote:

tmsg wrote:Thanks a lot for that, I am really using incremental search a lot.

You are welcome to post any issues/ideas about FiL (FindInLines) here or in github page of Cud (better).

Will do.

I have just separated FiL from the rest of cuda_ext (so I don't need the latter with its many functions) and also done a few changes as well. Some are simply personal preferences (ie added a couple of keyboard shortcuts and changed the rest to my prefs). There are maybe two things that may be good for general use, both reflecting that I am using the input field (left) a lot more than the combobox (right): first I've made the input field resizable and also a lot wider and second I've made sure that the input field always gets the focus, no matter what the pfid field from the stored options says or whether the focus last time was on the combobox. Now, I am not saying that this is the general use case but perhaps an option on which field to focus initially (always what, always whti, or last one) might be good.

Otherwise, again thanks for a valuable plugin and also an opportunity/excuse to learn some basics about writing Cud plugins

@Alexey: Yes, Lua is fast, but LuaJIT is faster It really is an amazing piece of software. It has always reminded me of Turbo Pascal 1.0 (I had used something called UCSD Pascal before TP and that was utterly horrible). I just couldn't believe how anyone could have put a complete Pascal compiler, its runtime and an editor into 33,280 bytes of code (I still have the original distribution for 1.00A here). Those were the days