Hello there,

Anyone here use that language?

From what i can tell so far, it looks like the most ridiculous language i have ever seen. That's because the syntax attempts to force the programmer to keep track of every space in the program lines. THAT seems like a discontinuity in how humans want to program because it nails down the form of the text into a overly rigid form.
For example, if you are declaring constants you can not do this in an attempt to line up the decimal points vertically:
x=___1.234 (the underscores are spaces really)
y=123.4

You MUST do it this way only:
x=1.234
y=123.4


Do i have this wrong? I only took a very short look at some of the documentation so far.

 

https://new.pythonforengineers.com/blog/favorite-programming-language-sucks/

Your Favorite Programming Language Sucks

 

Most languages do not consider "whitespace" as a semantic (meaningful) entity, and in fact may languages compress multiple consecutive occurrences of "whitespace" into a single space.

 

Hello there,

Anyone here use that language?

From what i can tell so far, it looks like the most ridiculous language i have ever seen. That's because the syntax attempts to force the programmer to keep track of every space in the program lines. THAT seems like a discontinuity in how humans want to program because it nails down the form of the text into a overly rigid form.
For example, if you are declaring constants you can not do this in an attempt to line up the decimal points vertically:
x=___1.234 (the underscores are spaces really)
y=123.4

You MUST do it this way only:
x=1.234
y=123.4


Do i have this wrong? I only took a very short look at some of the documentation so far.

On what basis do you claim that "you MUST do it this way only"?

Have you bothered to try it?

It works just fine:

x =   1.234
y = 123.4

print(x+y)

produces:

>>> %Run junk.py
124.634
>>>

While I do not like the decision that Python made regarding using whitespace to determine code structure, there is a very sound motivation for doing so -- namely to tie the physical structure as perceived by the vast majority of humans when looking at the code to the logical structure as determined by the compiler. Countless hours have been wasted by programmers trying to figure out why, as an example, the following code results in an infinite loop (using C as an example).

count = 0;
sum = 0;
while (count < 10)
   sum += count;
   count++;

Because they perceive the two indented lines as being the body of the loop, failing to recognize that the second indented line is only indented visually, not logically. This is a very common mistake that often happens when a control structure originally only controlled one line of code but then an additional line is added later without realizing that now delimiters are required whereas with a single line they were optional.

This is essentially a variant of the dangling-else problem that haunts many languages, but not Python.

The frustrating thing about Python's approach is that not all whitespace is equal, so while an indentation of eight spaces might look indistinguishable to an indentation of two tabs or of a tab followed by four spaces, these are all different. So it's important to adopt a consistent format, the preferred way in the Python community being that each level of indentation is done with exactly four spaces. Fortunately, most IDEs can be configured to automatically convert tabs to spaces and lint checkers can be used to verify adherence to the language preferences.

Python's use of dynamic types is also a big stumbling block for people that learned to program in a statically typed language. But this is really a reflection of, having learned to program with statically-typed languages, they have also learned how to leverage the strengths and overcome the limitations of statically-typed languages. You just have to learn how to leverage the strengths and overcome the limitations of dynamically-types languages to program well in Python. It's really neither better nor worse, it's just different.

My biggest problem with Python is that it has a track record of breaking all of your code by not being backwards compatible. After the Python 2 to Python 3 debacle, the assertion was made that this wouldn't happen again. If I produced applications that needed to be supported and updated for years to come, would I really be willing to rely on such an assertion? I doubt it. Since I primarily use Python for things that only I (or a small number of coworkers) use and that don't have to be maintained for the next two or three decades, I can take the risk.

 

On what basis do you claim that "you MUST do it this way only"?

Have you bothered to try it?

It works just fine:

x =   1.234
y = 123.4

print(x+y)

produces:

>>> %Run junk.py
124.634
>>>

While I do not like the decision that Python made regarding using whitespace to determine code structure, there is a very sound motivation for doing so -- namely to tie the physical structure as perceived by the vast majority of humans when looking at the code to the logical structure as determined by the compiler. Countless hours have been wasted by programmers trying to figure out why, as an example, the following code results in an infinite loop (using C as an example).

count = 0;
sum = 0;
while (count < 10)
   sum += count;
   count++;

Because they perceive the two indented lines as being the body of the loop, failing to recognize that the second indented line is only indented visually, not logically. This is a very common mistake that often happens when a control structure originally only controlled one line of code but then an additional line is added later without realizing that now delimiters are required whereas with a single line they were optional.

This is essentially a variant of the dangling-else problem that haunts many languages, but not Python.

The frustrating thing about Python's approach is that not all whitespace is equal, so while an indentation of eight spaces might look indistinguishable to an indentation of two tabs or of a tab followed by four spaces, these are all different. So it's important to adopt a consistent format, the preferred way in the Python community being that each level of indentation is done with exactly four spaces. Fortunately, most IDEs can be configured to automatically convert tabs to spaces and lint checkers can be used to verify adherence to the language preferences.

Python's use of dynamic types is also a big stumbling block for people that learned to program in a statically typed language. But this is really a reflection of, having learned to program with statically-typed languages, they have also learned how to leverage the strengths and overcome the limitations of statically-typed languages. You just have to learn how to leverage the strengths and overcome the limitations of dynamically-types languages to program well in Python. It's really neither better nor worse, it's just different.

My biggest problem with Python is that it has a track record of breaking all of your code by not being backwards compatible. After the Python 2 to Python 3 debacle, the assertion was made that this wouldn't happen again. If I produced applications that needed to be supported and updated for years to come, would I really be willing to rely on such an assertion? I doubt it. Since I primarily use Python for things that only I (or a small number of coworkers) use and that don't have to be maintained for the next two or three decades, I can take the risk.

Hi,

I was hoping to get some counterpoints because i hated to think that it could really be this way.

From the first example you typed, I found in the documentation an example like that that said it would not work, thus I assumed that was right. I'll double check that.

The second example you typed i see is exactly part of what i was talking about. They appear to be forcing you to use 4 spaces for indents. That's kind of a rigid requirement I think.
Since the beginning of time I have used just 2 spaces for indents. The reason for this is because if you have a deeply nested set of loops or conditional statements 4 spaces takes you too far across the page horizontally. Using 2 spaces allow you to have most of it visible without scrolling horizontally. It's half as much.
Is there a way to change from 4 to 2 spaces? That could solve the problem. I may not have a hard time dealing with it then because i always type using this format and never deviate from that. This means all of the code i have written in the last 25 years or more has proper indents already.

The real issue i see here again seems to be the 'daddy' issue, or "big brother" issue. Do i really need someone else with bright ideas dictating the way i should have to type my code, or what functions i should be using? If i was an idiot, maybe. Assuming i was not an idiot, maybe not.
This falls into a similar category of "to use goto's or not to use goto's" where the language author decides they should dictate whether or not to use a goto or not, and not allow the programmer to decide for themselves. Using a goto to not a goto is a policy, not a mandate. Each person or company or professor should be able to set the policy themselves.

In any case, if we could change the four space requirement to just two spaces i may be able to live with it. I considered this only because someone asked me to look into it, but i would consider using it also because other people are using it and it seems to be at least a little in widespread usage.

 

Most languages do not consider "whitespace" as a semantic (meaningful) entity, and in fact may languages compress multiple consecutive occurrences of "whitespace" into a single space.

Hi,

Thanks, and yes i realize that. This issue though is about the source code text. If you can not set up some code in the format (using spaces for example) you want to use, it can be harder to read over later.
WBaln seems to be implying that the case for declaring variables is not want the doc's i have read so far would indicate, so i have to look into this more.

 

I'm not a programmer, but couldn't you use 'Search and Replace' to convert your source code from 2-space to 4-space easily?

 

Hi,

Thanks, and yes i realize that. This issue though is about the source code text. If you can not set up some code in the format (using spaces for example) you want to use, it can be harder to read over later.
WBaln seems to be implying that the case for declaring variables is not want the doc's i have read so far would indicate, so i have to look into this more.

The choice to use significant whitespace in Python has always been controversial.

In practice, it simplifies the parser and creates a basic common framework that makes reading other people's code easier. Coming from Perl, where whitespace is absolutely not significant, it rankles—but stepping back I can see it's jut a choice by the original author of Python with both up- and downsides.

Python is one of the most widely used languages in scientific and technical programming. It is used by many excellent programmers who have no problem with the whitespace and formatting requirements. It is the tiniest of stumbling blocks if you don't artificially inflate its significance.

I would strongly advise to look past it to the upsides and enormous utility of Python. Taking a step back, you might find that from a "more objective" position, your response to this inconvenient novelty seems quite exaggerated and with the smallest of accommodations on your part it will be completely irrelevant to your use of Python and the benefits you will derive.

 

I'm not a programmer, but couldn't you use 'Search and Replace' to convert your source code from 2-space to 4-space easily?

There are many editors with excellent Python support so any sort of automatic accommodation for the significant whitespace requirement that is useful to the programmer is already out there to use—it's just a matter of choosing and using an editor one likes.

 

Surely considered by many a bad practice if at all useful, could you consider padding with zeroes on the left?

 

In any case, if we could change the four space requirement to just two spaces i may be able to live with it. I considered this only because someone asked me to look into it, but i would consider using it also because other people are using it and it seems to be at least a little in widespread usage.

You can use whatever non-zero number of indentation spaces you like and you can mix all possible combinations in a single code document. All the indentation does is define the scope.

What are these docs you say forbid white space per post #1?

 

I'm not a programmer, but couldn't you use 'Search and Replace' to convert your source code from 2-space to 4-space easily?

Hi,

Well, when debugging that makes it very difficult. That's like using a preprocessor for all the code to convert your own syntax into that which the compiler uses. Just adds another step which make it harder to use, not that it is impossible though.
I actually wrote a program a long long time ago to convert Pascal into Basic (ha ha). I liked Pascal better so i liked to write in Pascal, or a Pascal-like language.

 

The choice to use significant whitespace in Python has always been controversial.

In practice, it simplifies the parser and creates a basic common framework that makes reading other people's code easier. Coming from Perl, where whitespace is absolutely not significant, it rankles—but stepping back I can see it's jut a choice by the original author of Python with both up- and downsides.

Python is one of the most widely used languages in scientific and technical programming. It is used by many excellent programmers who have no problem with the whitespace and formatting requirements. It is the tiniest of stumbling blocks if you don't artificially inflate its significance.

I would strongly advise to look past it to the upsides and enormous utility of Python. Taking a step back, you might find that from a "more objective" position, your response to this inconvenient novelty seems quite exaggerated and with the smallest of accommodations on your part it will be completely irrelevant to your use of Python and the benefits you will derive.

Hi Ya'akov,

That sounds very reasonable, maybe I just reacted badly partly because I was tired out at the time too and partly because I am so used to doing the formatting the way I like to do it and I do not vary from that anyway.

It would take time for me to adapt to the 4 space indent issue. I went to 2 spaces because I often create deeply nested loops or conditionals, which can sprawl across the page. 4 spaces means the text goes farther over to the right.

Yes, I see your point clearly here. It is still a matter of pro's and con's, and the pro's may beat the con's by a long shot, thus I will have to look more deeply into this programming language.

Thanks for presenting a more balanced view of this programming language.

 

There are many editors with excellent Python support so any sort of automatic accommodation for the significant whitespace requirement that is useful to the programmer is already out there to use—it's just a matter of choosing and using an editor one likes.

Hello again,

This would be a stumbling block for me depending on how different it is.

That's because long ago (and currently also) I wrote my own text editor, if I can actually call it that. I did this because I did not like any of the editors I came across for one reason or another.
My editor can do a lot, lot more than any editor I have ever seen, including search out different things in the source files, and offer some context help, etc. It also does other things though you dont usually see text editors doing.
For example, here is a short list:
1. Opens files on the host computer with a double click, just like a file manager.
2. Does directory listings, and provides a hard copy of the result, in a tree list format.
3. Displays file properties.
4. Does file backups on command.
5. Does reverse file backups (restore files).
6. Does conversions for different math formats.
7. Does symbolic electronic circuit analysis.
8. Spell checks.
9. I have another text editor for math mostly, and that solves ODE's, but I can use that as a plug in with my main text editor here.

There's a lot more to put on that list but I think this makes the point that there is almost no chance I would ever switch to another editor. I've been working on that editor on and off since circa 1998.

One thing I almost forgot though, I can change the indents from 2 to 4 with one of the menu options. I forgot about that because I never use it except to go the other way, from 4 to 2 indents, which I haven't needed in a long while now. This means there is a very good chance I can use it for Python without any modifications, although I would add help files to the current ones to look up help in Python also, provided I find good help on the web.

So all is not lost, yet

 

You can use whatever non-zero number of indentation spaces you like and you can mix all possible combinations in a single code document. All the indentation does is define the scope.

What are these docs you say forbid white space per post #1?

I will be looking up that help again so I will see if I can find it again.

 

Hi,

I was hoping to get some counterpoints because i hated to think that it could really be this way.

From the first example you typed, I found in the documentation an example like that that said it would not work, thus I assumed that was right. I'll double check that.

The second example you typed i see is exactly part of what i was talking about. They appear to be forcing you to use 4 spaces for indents. That's kind of a rigid requirement I think.
Since the beginning of time I have used just 2 spaces for indents. The reason for this is because if you have a deeply nested set of loops or conditional statements 4 spaces takes you too far across the page horizontally. Using 2 spaces allow you to have most of it visible without scrolling horizontally. It's half as much.
Is there a way to change from 4 to 2 spaces? That could solve the problem. I may not have a hard time dealing with it then because i always type using this format and never deviate from that. This means all of the code i have written in the last 25 years or more has proper indents already.

The Python interpreter doesn't care about the details of what kind of indenting you use, just that you do it consistently. You can use a tab followed by a space for the first level of indent and two spaces and a tab for the second level for all it cares. So if you want to use two spaces, use two spaces. I grew up using three. I am generally willing to use whatever the editor I am using has as its default unless it is really obnoxious (like eight).

Furthermore, it only has to be consistent within a given block of code. So you could have a while() loop at the top of your code that uses 4 spaces for indent and then later on a heavily-nested if() structure that only uses a single space for each level of indent. The interpreter merely detects the indentation pattern based on the first line of indented code within a block and then uses that as the pattern it requires for all subsequent lines of code at that level within that block. Since a line of code that is indented three levels is actually indented three times, it has to have the proper pattern for the each level in turn.

The real issue i see here again seems to be the 'daddy' issue, or "big brother" issue. Do i really need someone else with bright ideas dictating the way i should have to type my code, or what functions i should be using? If i was an idiot, maybe. Assuming i was not an idiot, maybe not.
This falls into a similar category of "to use goto's or not to use goto's" where the language author decides they should dictate whether or not to use a goto or not, and not allow the programmer to decide for themselves. Using a goto to not a goto is a policy, not a mandate. Each person or company or professor should be able to set the policy themselves.

Then only write programs in assembly.

Oh, wait, whoever wrote the assembler is going to impose on you constraints on how you write your code. Better just to get a hex editor and enter the opcodes you want directly.

But then you have to live with the constraints that the designer of the CPU is going to impose on you. Just design your own processor so that you can decide for yourself what you want it to do.

But then you have to live with the constraints imposed on you by the people that designed the fabrication process you are going to use. Damn, where do all the daddy issues stop?!

The point is that you will always have to live within the constraints imposed by the tools you use.

As for the idiot assumption, the mere existence of widespread code that has all kinds of bugs and vulnerabilities that we have known for decades how to avoid is pretty compelling evidence that a large fraction of programmers need to have big brother, in terms of language constraints, looking out for them.

It's interesting that so many programmers (and I freely admit I used to be firmly in this camp and still have tendencies in this direction) chafe at having languages impose constraints on them. What they are really doing, however, is basically asserting that they know everything there is to know about writing good, safe, secure, error-free code and how dare some language assume that they don't. The reality, however, is no different than countless other situations in which the amateur reaches a level of competence that lulls them into thinking that they have learned everything there is about a subject, while the professional has reached a point where they continually become ever more aware of just how much there is that they don't know.

So I no longer begrudge languages looking out for me. If I really can't tolerate it in a particular situation, then I can opt to use a language that does less hand-holding and gives me more control, acknowledging that with that control also comes the responsibility to be sure that I wield it wisely and correctly.

What I do see as a problem, however, is the natural trend toward not even bothering to educate programmers about the issues that they are being protected against. That's turning them into true monkeys at a keyboard that are completely reliant on the language looking out for them. Again, it's not just programming, but many areas in which we are increasingly the victims of our own technological success. I fear it's going to bite us big time some day.

In any case, if we could change the four space requirement to just two spaces i may be able to live with it. I considered this only because someone asked me to look into it, but i would consider using it also because other people are using it and it seems to be at least a little in widespread usage.

Again, use what you want, just be consistent. Having said that, there is value in adhering to the conventions of the community. Just like four spaces is the convention for the Python community, there are conventions for naming functions and variables and many other things. If you are going to be trading code with other members of the community, or working on joint projects, then abiding by those conventions is worthwhile. If you are just keeping your code to yourself, then it doesn't matter.

 

Hi Ya'akov,

That sounds very reasonable, maybe I just reacted badly partly because I was tired out at the time too and partly because I am so used to doing the formatting the way I like to do it and I do not vary from that anyway.

It would take time for me to adapt to the 4 space indent issue. I went to 2 spaces because I often create deeply nested loops or conditionals, which can sprawl across the page. 4 spaces means the text goes farther over to the right.

Yes, I see your point clearly here. It is still a matter of pro's and con's, and the pro's may beat the con's by a long shot, thus I will have to look more deeply into this programming language.

Thanks for presenting a more balanced view of this programming language.

I use two-space tabs as well so the code doesn’t slide too far off the screen.

It really does require analyzing the cost-benefit tradeoff. I am not a super-fan of Python but I have to give it what it is due. It has been so widely adopted in the science/math/experimental community that knowing and using it is an instant leg up if you are doing anything related. There are excellent libraries for Python in specialist areas, including one the best big number libraries.

I don’t know what you program in now, but if you are not using a dynamic language that will take a bit of getting used to. Again, it has advantages and disadvantages. Some people insist on calling Python* programs “scripts” because they believe they aren’t “real” programs.
* and Perl, and Javascript, &c

This is just word games without content. Because of the confusion concerning the difference between what is a script and what is a program, some time ago I spent quite a bit of effort researching the question and discovered there was no real difference in the context of dynamic vs. fully* compiled programming languages. It just isn’t a thing, and even if it was, it wouldn’t confer some special goodness on the “programs” compared with the “scripts”.
*fully compiled because dynamic languages generally use a combination of intermediate compilation and interpretation of the intermediate code

In practice, I finally decided to make the word “script” somewhat useful by making the following distinction:

Regardless of the nature of the programming language for which it is written a script is distinct from a program to the extent that the script is written primarily to automate the actions of a program or programs; while a program is written primarily to complete some action directly and not through other programs.

For me, this makes using the two different words helpful in distinguish the role of a program, and to some extent the nature of the code in it.

In any case, if dynamic languages are new, you are going to find some very useful things they can do. Make sure to take advantage of them. I tell aspiring Perl programmers who are coming from a C/C++ background, and are writing Perl as if it was C, that C is a great language for writing Perl, but a terrible way to write perl code.*
*Perl is written in C (and Perl), but using C syntax and methods in Perl code completely misses the point of Perl

If you are going to learn Python, learn it all the way. Learn to program in it as Python programmers do. Try not to smuggle in a bunch of baggage. After you‘ve learned it fairly well, you may find a place for habits, structures, and methods you have learned for other languages—but wait until you know how to program “natively”.

Good luck, and have fun.

 

Surely considered by many a bad practice if at all useful, could you consider padding with zeroes on the left?

That can have unintended consequences, as I found out the hard way in some C code I wrote years ago. I passed values in a table with leading zeroes to make the table nice and neat and uniform -- and in the process turned values from decimal to octal numbers and, unfortunately, none of the affected numbers had 8 or 9 as digits and so it was perfectly valid code, that now produced all kinds of bad output and it took hours to track it down.

Python, IIRC, doesn't use this syntax for octal, instead it uses a "0o" prefix, specifically to avoid this issue.

 

Hello again,

This would be a stumbling block for me depending on how different it is.

That's because long ago (and currently also) I wrote my own text editor, if I can actually call it that. I did this because I did not like any of the editors I came across for one reason or another.
My editor can do a lot, lot more than any editor I have ever seen, including search out different things in the source files, and offer some context help, etc. It also does other things though you dont usually see text editors doing.

There's a lot more to put on that list but I think this makes the point that there is almost no chance I would ever switch to another editor. I've been working on that editor on and off since circa 1998.

It’s great that you‘ve found an editor that works for you, and cool that wrote it. Very nice.

I would do a little research before claiming that it is more capable or feature rich than others. I don’t see anything on your list at first glance that modern editors can’t do—either natively or with plugins. Editors have come a very long way, and modern ones, with IDE features, are pretty damned amazing.

I think if you did some looking around now, you’d find that there are many options that can do what you want(ed). Of course, you are “married” to the current editor and have a big investment in it, of both time and psychological attachment. ”If it ain’t broke…” is surely an apt maxim in this case, and there’s probably no reason to bother looking around.

Still, you might get some ideas to enhance your own editor—or, who knows, find something you like better(!) and port your features to it as plugins…

 

The Python interpreter doesn't care about the details of what kind of indenting you use, just that you do it consistently. You can use a tab followed by a space for the first level of indent and two spaces and a tab for the second level for all it cares. So if you want to use two spaces, use two spaces. I grew up using three. I am generally willing to use whatever the editor I am using has as its default unless it is really obnoxious (like eight).

Furthermore, it only has to be consistent within a given block of code. So you could have a while() loop at the top of your code that uses 4 spaces for indent and then later on a heavily-nested if() structure that only uses a single space for each level of indent. The interpreter merely detects the indentation pattern based on the first line of indented code within a block and then uses that as the pattern it requires for all subsequent lines of code at that level within that block. Since a line of code that is indented three levels is actually indented three times, it has to have the proper pattern for the each level in turn.



Then only write programs in assembly.

Oh, wait, whoever wrote the assembler is going to impose on you constraints on how you write your code. Better just to get a hex editor and enter the opcodes you want directly.

But then you have to live with the constraints that the designer of the CPU is going to impose on you. Just design your own processor so that you can decide for yourself what you want it to do.

But then you have to live with the constraints imposed on you by the people that designed the fabrication process you are going to use. Damn, where do all the daddy issues stop?!

The point is that you will always have to live within the constraints imposed by the tools you use.

As for the idiot assumption, the mere existence of widespread code that has all kinds of bugs and vulnerabilities that we have known for decades how to avoid is pretty compelling evidence that a large fraction of programmers need to have big brother, in terms of language constraints, looking out for them.

It's interesting that so many programmers (and I freely admit I used to be firmly in this camp and still have tendencies in this direction) chafe at having languages impose constraints on them. What they are really doing, however, is basically asserting that they know everything there is to know about writing good, safe, secure, error-free code and how dare some language assume that they don't. The reality, however, is no different than countless other situations in which the amateur reaches a level of competence that lulls them into thinking that they have learned everything there is about a subject, while the professional has reached a point where they continually become ever more aware of just how much there is that they don't know.

So I no longer begrudge languages looking out for me. If I really can't tolerate it in a particular situation, then I can opt to use a language that does less hand-holding and gives me more control, acknowledging that with that control also comes the responsibility to be sure that I wield it wisely and correctly.

What I do see as a problem, however, is the natural trend toward not even bothering to educate programmers about the issues that they are being protected against. That's turning them into true monkeys at a keyboard that are completely reliant on the language looking out for them. Again, it's not just programming, but many areas in which we are increasingly the victims of our own technological success. I fear it's going to bite us big time some day.



Again, use what you want, just be consistent. Having said that, there is value in adhering to the conventions of the community. Just like four spaces is the convention for the Python community, there are conventions for naming functions and variables and many other things. If you are going to be trading code with other members of the community, or working on joint projects, then abiding by those conventions is worthwhile. If you are just keeping your code to yourself, then it doesn't matter.

Hello again,

That's very interesting for sure and addresses some of the issues i was looking at.
For the first, the indents. I did not know that consistency was the rule as everything i have read so far says four spaces and nothing else. The fact that i could use 2 spaces is very enlightening.

Yes, i think you struck a nice balance between what is a given hard and fast rule and what is not to be desired. That makes sense too.
You may find it ironic that i have built my own assembler for the Z80 back in the 1980's and even built my own CPU back then too. The assembler was quite capable, but the CPU took up an entire PC board around 4x6 inches maybe larger this was a long time ago, and was very basic with a very basic ALU.
You may have went a little too deep with this idea though because the main issue was only about the text editor, but it does make sense just the same.

The thing I like about my own personal text editor is the same as all the software I write, mostly for Windows. That is, I can change or add to the code anytime it seems necessary. That means the functionality can be changed a lot and adding that functionality is also a possibility, and because of the language I use it is not that difficult to do.
Just the same, there is a chance I would like to use another text editor, but right now I have not looked around very much because I never intended to stray from the one I use now. That could change now though since I've heard about these other text editors.
One of the down sides is that there are often bugs in the editors. Case in point, the editor that came with one version of the Watcom compiler. Note that I have not used this in a long while now, things may have gotten better with that. With my own editor if something comes up, I can usually find the problem in less than 30 minutes. This is true with a lot of my own personally written programs, and i found it very frustrating to run into bugs in other people's programs because i had no way to fix them, or it would be hard to fix them. Case in point, Maxima. That went through several versions, and with each new version something is fixed and something else is broken. I could be wrong, but I attribute that to code writers that are not in good enough communication or the code comments are now adequate. It's very hard to keep good comments that can describe exactly why a function was written in a certain way, and when a new programmer comes on the scene, they don't understand all that background info probably because it was not even written down yet.

In spite of all that I will still look at some other text editors now and see what I can find. I'll try to report back here what looks good and what looks not-so good.

Thanks for the outline and the ideas.