LiveCode Forums.

A field is created and characters are typed into the field. Any character can be made into a subscript or superscript, on the first attempt. But, it the character is changed back to a normal character, it can never be changed back to superscript or subscript again. Not only that, but no other text in the field can ever be made into a sub or superscipt, after that, either. That's pretty unforgiving for a typo error! Please fix, as I am a physics/chemistry teacher, and this software is useless for scientific purposes without a working super/subscript font. Thanks!

Duane Parker

Thanks for posting that, Duane. I looked into it, and found that there's an existing report for this - I've added some notes just now with what I found while exploring this in response to your post:
http://quality.livecode.com/show_bug.cgi?id=14079

While that is an annoyance in the IDE, and an engine enhancement could make it more convenient to work with, I didn't find anything that would prevent you from writing applications that user super- and subscript.

If you need any help getting going on that post what you have and we'll help refine it.

About a year ago I first reported this bug. It still is not fixed.

You said, "While that is an annoyance in the IDE, and an engine enhancement could make it more convenient to work with, I didn't find anything that would prevent you from writing applications that user super- and subscript. If you need any help getting going on that post what you have and we'll help refine it."

This is more than an "annoyance." This is a bug! You should not be talking to me about an "enhancement" to "make it more convenient to work with." You should be boosting the priority of this bug and sending the project on to your programmers. This is a malfunctioning part of the interface. If a menu includes "subscript" or "superscript" it ought to work without having to create an app to do the same thing. What would prevent me from writing my own applications that uses super- and subscript? Time. Inexperience using LiveCode. Common sense. I don't want help creating my app to do what is supposed to happen when you use a menu item on LiveCode's interface. Enhancement?! More convenient?! If all I had to do was retype the word when it got "stuck in neutral" on superscript/subscript, that might be tolerable.The bug affects the whole field, not just a character or two! As it stands now, the only way to change a superscript to a subscript is to create a whole new field and enter all the text all over again. That's the electronic equivalent of having to retype a whole page of text, if you make a single mistake. Worse than that, if you have any scripts involved that reference the deleted field, they now have to deal with a field a different name.

Is LiveCode what it says it is--a programming environment that allows a person to go from idea to product in no time? You can't accomplish that if primitive text functions are not even available in the interface. There are other abnormal elements in the interface, as well, such as some issues with word wrapping, and the appearance of characters in grids. I keep hoping someone will consider basic functions like this as, well...basic. You are frustrating would-be LiveCode programmers such as myself, by releasing a product with a broken interface. I have started trying to use various versions of this product at least 5 times over the years, only to meet with some barrier such as this after a few minutes of trying to make some simple stack. When I tell my friends about LiveCode, I always end up saying it has a glitchy interface.

duanep wrote:You should not be talking to me about an "enhancement" to "make it more convenient to work with." You should be boosting the priority of this bug and sending the project on to your programmers.

As a volunteer Community Liaison I meet now and then with members of the core dev team to coordinate community initiatives. But mine is more of an ombudsman role, as we see in many open source projects, and I neither run their company nor control their team's priorities.

On the contrary, the time I spend here is purely as a volunteer, taking time I might otherwise spend with family or clients or my on projects to try to be helpful to others, such as yourself.

What you've discovered is indeed a bug in the LiveCode IDE, and those who've reviewed it agree it should be fixed. But even though this issue may seem critical at the moment for your work, in all fairness I have to note that in all my years across every venue discussing LiveCode I don't recall seeing anyone else even mention this at all.

In fact, I'm adding subscript and superscript features to one of my apps this morning, and can confirm once again that this is fully working in the engine you'll use when you ship your app, limited only in the IDE's UI provided for it during development.

Just the same, I do agree that it should be addressed. That's why I'd already satisfied your demand long before you wrote it, having added analysis to the report to help move it toward resolution.

If you're looking for ways to help the core team assess priorities, please keep in mind that as a practical matter they rarely abandon the tasks we ask them to do to go hunting through these user-to-user support forums on the odd chance that they might find relevant guidance.

Since you have the URL to the bug report, have you considered adding your comments there where they might become actionable?

In addition to the analysis I added to that report after your first post here, I also added a follow-up this morning for you. The bug DB is the best way to contribute details directly to the core team which can help an issue get resolved.

The team will get to it as soon as they can, but with so many other users asking for so many other things, please understand that, like all software projects, they have to weigh priorities by severity, scope, and opportunity. It would indeed be great if LiveCode could be the first software of its scope that's entirely bug-free, but 50 years of ACM literature shows us nothing like that. So for now, as with any other software, we need to look at solutions with the resources we have in hand.

Beyond waiting for the core team, this could just as well be fixed by anyone in the community. With more than 75% of LiveCoders using the free and open Community Edition, like any healthy open source project we frequently see contributions from community memebers. If you can find anyone else whose work is affected by this perhaps they could be encouraged to review my notes and fix it even sooner than the core team might be able to.

In fact, having done the analysis I'd submitted I could probably fix that bug myself in just a couple hours. But at the moment nothing anyone is paying me to work on is in any way affected by it. So as much as I enjoy volunteering when
I can, I trust you can appreciate that I must prioritize my development time in ways that favor the clients that pay my company's bills.

That said, this bug won't affect your app's functionality either, or any other app made with the LiveCode engine. As you know from reading the report, the issue is limited to the IDE and does not affect the engine we use to build our apps.

While this was your second post in our community here, I've been working with LiveCode since 1997. I have a fairly good understanding of how it works, and how to achieve good results with it.

If your app needs to provide support for subscript and superscript, that's governed by the textShift property applied to text runs. The Dictionary entry for that property describes how we use it in our apps.

FourthWorld (Richard),
Thank you for volunteering your time to help others. I can see that, as I get into this LC world, there are aspects of the organization, especially one involving so many volunteers, and how to get things done, that I know little of. Until the last hour, I have been unaware that there even was a place to report bugs, separate from the forums. Please understand, however, that things that may be very easy for an experienced LC programmer to do, are beyond the skill level of many who would like to use LC. I'm not even sure of what somethings you said even mean:

"this is fully working in the engine you'll use when you ship your app, limited only in the IDE's UI provided for it during development."
"this bug won't affect your app's functionality either, or any other app made with the LiveCode engine."

I guess that means it's not WYSIWYG, during development, but would work as expected if you made an app and shipped it. If that's what that means, it still is of little comfort, as I would like to see what the user will experience, even while I develop the app.

I worked for a software company for two years, testing software and customizing the interface for their engine, inventing (programming) in-house tools in VBA for Excel to do some of the testing and customization. In fact, some of what I created remained a key part of that business' daily operations for 15 years after I returned to teaching. I'm fully aware of the certainty of bugs and the triage that must govern what gets attention. What I can't understand is how someone hasn't taken the bull by the horns regarding the LiveCode interface to make sure it at least comes up to the standard of a basic text editor or a rudimentary spreadsheet, in text fields and grids.

Why others, particularly those in math or science, haven't complained about this issue (sub/superscripts in the UI) I couldn't say. I'm amazed they haven't. Perhaps, they came, saw, and left, realizing it was not the tool for them. Maybe 99% of your users and developers, are using it for something outside of science and math. If so, maybe I'm an odd ball. But, I certainly can see how those who are interested in using LC with science and math would not give it a second look, with issues like this sub/superscript problem. I guess what I am saying, is that I think programmers get tunnel vision, and forget the experience of those newbies like myself, who are trying to get on-board, but keep running into problems that for them are not "second nature" to solve, as evidently they are for you. I can't just "create an app." For me, it cannot be fixed in a couple of hours. It's a catch-22, that has resulted in many false starts and doubts as to whether LiveCode is what it says it is--easy to use, and whether it will ever be a program I can use. I am beyond frustrated with LiveCode, but I fell in love with HyperCard about 3 decades ago, and have been looking for my home ever since Apple abandoned it and all of us HC programmers.

Your said "I trust you can appreciate that I must prioritize my development time in ways that favor the clients that pay my company's bills."

I don't know what company you work for, since you say you volunteer for RunRev, but I am a paying customer to RunRev. I would like to feel like my requests for basic functionality will not be treated like a beggar with his hand out. Furthermore, I hope someone in the process somewhere cares about the experience of those who trying to get on board with LiveCode but are not full-time programmers by trade.

Thanks for your attention to the issues, I brought up. Perhaps, a fix will be hastened by your action.

.......

Okay, I just tried it and I see what you mean.

The IDE (the development environment) is written in LC itself, it's all just a bunch of stacks. The LC engine that runs the IDE is the same one that gets embedded in your stack when you create a standalone. What Richard is saying is that the bug is in the IDE stacks, and not in the engine that runs everything. It's the same as if you had a bug in your own scripts.

The LC IDE scripts are open and anyone can fix the problem -- but the scripts are complex enough that few are brave enough to wade in there. And the engineers on the LC team are so busy working on the engine that they have to prioritize scripting issues like this one.

But one reason it may not be high priority is because there is a fairly easy work-around for us users. It isn't great, but it seems to work with a minimal amount of effort: when a character gets "stuck" and won't super/subscript any more, just delete it. Then re-type it and it's good as new again. This only requires retyping a single character, so it isn't so awfully terrible, and hopefully someone who is more lion-hearted than I am will feel brave enough to go rooting around in the morass that is the LC scripting environment and fix it some day.

......

duanep wrote:FourthWorld (Richard),
Thank you for volunteering your time to help others. I can see that, as I get into this LC world, there are aspects of the organization, especially one involving so many volunteers, and how to get things done, that I know little of.

Neither do we, or most other open source projects. Open source process is very different from processes that limit their contributors to those working in a single company, and all of us are finding our way as we go. Even large projects like Ubuntu, the Linix-based OS I use most of the time, is not without its procedural issues. But we learn by doing, and share what we learn, and together the open source world is producing some of the world's best software (Linux is the world's largest single software project). Warts and all the process seems to be moving things forward pretty well.

Until the last hour, I have been unaware that there even was a place to report bugs, separate from the forums.

That's why I provided the link to the bug report for this item last December. Many large projects use a bug DB, and most open source projects make their bug DB publicly accessible so everyone can participate in filing bugs and tracking their progress.

This "Bug Triage" forum can be useful for cases where we see something we don't understand or doesn't seem right, but we can't quite decide if it's a bug or come up with a repeatable recipe for it. Once we have a good recipe it can be acted on, and then we submit it to the bug DB.

Keep in mind that the bug DB is also where we log enhancement requests for new features or refinements to existing ones. When creating a new record there you'll have the option of flagging the report as a Bug or Enhancement. As you find opportunities to improve the worklow please feel free to submit requests for those.

Please understand, however, that things that may be very easy for an experienced LC programmer to do, are beyond the skill level of many who would like to use LC. I'm not even sure of what somethings you said even mean:

"this is fully working in the engine you'll use when you ship your app, limited only in the IDE's UI provided for it during development."
"this bug won't affect your app's functionality either, or any other app made with the LiveCode engine."

I guess that means it's not WYSIWYG, during development, but would work as expected if you made an app and shipped it. If that's what that means, it still is of little comfort, as I would like to see what the user will experience, even while I develop the app.

I hear ya'. We all start from zero knowledge, and even now all these years later I find the scope of LC so broad and always growing that I learn new ways to use it almost every week.

The part about your apps vs the IDE is about the IDE's focus: while I sometimes use it as a general text editor and frequently use it as a drawing app, its main purpose is to develop applications for others to use.

When used for that purpose textShift works very well, allowing us to deliver Superscript and Subscript functionality to our users.

It's cool that the LiveCode IDE also provides features most commonly found only in word processing apps, drawing tools, and other things not normally part of a software development tool (AFAIK neither XCode, Visual Studio, nor even Xojo or most others offer Superscript and Subscript in their IDEs at all), but those GUI capabilities are icing on the cake of its core language.

In fact, as you learn more about the scope of the language you'll find many things the IDE doesn't provide a GUI for at all, like some of the paragraph-level formatting options the new text engine supports (borders, border styles, column alignment, padding, etc.).

It might be nice if it did, but realistically the IDE already provides GUI features so far beyond most IDEs, and those features are somewehat specialized, that the effort needed to deliver a GUI for every language element would have such a low ROI as to be prohibitive.

I'm fully aware of the certainty of bugs and the triage that must govern what gets attention. What I can't understand is how someone hasn't taken the bull by the horns regarding the LiveCode interface to make sure it at least comes up to the standard of a basic text editor or a rudimentary spreadsheet, in text fields and grids.

Why others, particularly those in math or science, haven't complained about this issue (sub/superscripts in the UI) I couldn't say. I'm amazed they haven't.

In addition to the many math teachers in our community, a significant number of the core developers at LiveCode Ltd. are graduates of the Math department at University of Edinburgh, including the lead developer Mark Waddingham.

It may help to consider the scope of use cases with LiveCode as they relate to this issue:

LC is used to make a very wide range of apps, including games, CMSes, utilities, database front-ends, workgroup collaboration tools, courseware, and much more. Of those, the number that need superscript is relatively slim.

Of those that need superscript, many (like myself) need to provide that feature for our users to use, rather than using it outselves directly in our app's content.

Of those that need superscript in their app's content, as you've found the feature works well the first time it's used, so most just use it, it does what they need, and they move on.

It's only when changing a superscript or subscript a second time, and only when using the IDE's menu items to do so rather than something we made for our app, that the bug becomes evident.

So this bug affects only the subset of the subset of the subset of users who meet all of the above criteria. Apparently that's a small number.

Your said "I trust you can appreciate that I must prioritize my development time in ways that favor the clients that pay my company's bills."

I don't know what company you work for, since you say you volunteer for RunRev...

That's helpful feedback - thanks. I've been here so long I forget that an ever larger number of newcomers here have no idea who I am. I've updated my sigline.

...but I am a paying customer to RunRev. I would like to feel like my requests for basic functionality will not be treated like a beggar with his hand out.

Of course no one intends for you to feel that way, and that's an unfortunate outcome. As a paying customer you're entitled to technical support from the company. You may consider writing them directly at support AT livecode.com to see if they may be in a position to reconsider this bug's priority.

No one has said they require you to fix this bug yourself. On the contrary, this is now the third time that I'll note here that everyone who's seen this bug wants to see that it gets fixed, including the core team member who confirmed the bug report.

But please understand that there are thousands of other paying customers too, and each of them is also asking the team to work on things. I've found no other company that even attempts to provide a high-level scripting language with integrated GUI elements as a core part of that language on as many different OSes as LiveCode. It's not a trivial task. And with an audience as diverse as ours, and with OS APIs frequently changing out from under us, the amount of work required to maintain and grow the platform to satify all those divese needs is quite significant.

Most bug reports get acted on fairly quickly, but up against the broad scope of what so many others require of them, like all software teams they need to prioritize fixes. While this specific issue is central to your work, in the scope of all the things all others use LiveCode for it is, to be fair, a bit of an edge case. It will be fixed, but something that affects such a small subset of a subset of a subset of users may require some patience. And in the meantime, if we can find anyone else in the community affected by this with some time and experience to lend a hand, this IDE issue could be resolved even quicker by any of us.

But I'll do one better: If you're writing forumulas, the odds that the IDE team correctly guessed the amount of vertical adjustment your specific use case requires is slim. So even when the Superscript and Subscript menu items are restored to full functionality, they still may not provide what you need. Although the textShift property supports a wide range of integer values, the IDEs menus provide only one fixed value.

So here's something that goes much further:

This is a plugin I wrote for you this morning, based on parts I'd already had in hand since as I noted I'm adding Superscript and Subscript to one of my apps right now. This not only works when using it multiple times on the same text run, but also provides a wide range of vertical offets you can choose from a popup list, all even numbered integers between -20 and 20, including zero (Currently it only offers even-numbered values, because I found that all values made the list too long; feel free to add or remove anything you like in that option control):
http://fourthworld.net/lc/SuperSub.livecode

Download it and put it in your Plugins folder, and it'll be available whenever you need it. It's in v5.5 stack file format so it should work well in all LC versions made over the last several years.

I didn't take the time to include docs or licensing, but to use it just select some text in any field in a toplevel stack and click the "Apply to Selection" button. As for licensing, this stack file is released into the public domain on 1 November 2016.

This may also provide some inspiration for other ad hoc tools you can make whenever you want one. Most of the code in the Apply button is just error-checking, the actual work is just a few lines. When making things for yourself you can often skip at least some of the tedium of handling errors since you already know what you expect it do.

Of course Plugins aren't a fix for IDE bugs. But I believe this one will be even more useful for you because it offers a level of flexibility that goes beyond what the IDE provides. Over time you'll no doubt think of other such goodies to simplify your workflow, and being able to just drop them into the Plugins folder to have them available easily is a wonderful thing.

[-hh] wrote:Take for example a field that has one line, the htmltext as follows (a typical situation of a line after several super-/subscript- edits).

Code: Select all

<p>CO<sub shift="0">2</sub> and O<sub shift="0">l</sub> is in
the air<sub shift="0">.</sub></p>

Shift the mistyped "l" (ell) after the second "O" down and then up again. Now look at the text only, try again subscripting and tell me then which character to delete. The htmltext remains unchanged. The whole line got stuck regarding super-/ subscripting not a certain character only.

You delete the "l", since that's the character you want to fix. Basically, if you find that a super-/subscript doesn't work, you delete the character and retype it. I do not see the problem where the entire line is unresponsive, though. I am able to subscript a different character even when the "l" doesn't work.

jacque wrote: You delete the "l", since that's the character you want to fix. Basically, if you find that a super-/subscript doesn't work, you delete the character and retype it. I do not see the problem where the entire line is unresponsive, though. I am able to subscript a different character even when the "l" doesn't work.

jacque, I tried what you said, and it, indeed, was an almost effortless "fix" ... most of the time. (The user has to figure it out, or read what you've said here to find it, but at least a solution exists.) There are permutations that will result in the whole field of text freezing up, leaving no recourse but to create a new field. I can't tell you exactly how I did it, but I've done it twice, since reading your post.

I tried to attach the stack, so you could see for yourself, but was unable to load a file with a "livecode" extension.

Richard, thank you very much for your concern. The plug-in you made fixes this particular problem with super/subscripts for me, and does indeed fuel my imagination with what maybe I could do someday in the way of creating custom solutions using LC.

I hear what you and Jacque have been trying to get me to see, namely that perhaps my expectations need some moderation in view of the real-world life inside a growing product/tool/community project like LiveCode. I'm willing to admit that there's no way I can appreciate the realities of having to assign priorities to everyone's concerns: free-users, customers--big and small, programmers of all sorts, sales and marketing, management, etc. Everybody thinks their problem is most important, and nobody understands the resources to fix those problems are limited. However, because I spent a couple of years working in quality control and customization of a software engine for a company of about 60 employees, I do realize more than many, some of what is involved.

I'm just saying, there is, or should be, an important distinction between bugs and enhancements, and customers have a right to expect menu items to perform predictably. Perfection and elegance in new or advanced features, less so. I want LiveCode to succeed. For now, at least, it is my engine of choice for making some ideas I have come to life. I don't do C++, Java, or html. I have a day job. Sadly, my experience of trying get into LiveCode has been like some mouse that can't get over the doorstep to get into the house. The threshold has been too high.

LiveCode, to me, is something of a contradiction in terms. At the same time promising to be a language that is easy to use, intuitive, and and a rapid development environment for the "rest of us", it also assumes its customers are experienced, developer zealots who are willing and able to scale huge learning curves to get to their destination. I realize it can succeed with both groups, but only if there is a stable, predictable experience for the newbie, and vast possibilities for the more dedicated. Sadly, LiveCode has put the priority on the latter, and is off-putting to the newbie. Richard, you spoke of addressing such things as a glitch in the IDE as basically trivial because it was a "subset of a subset of a subset." I submit that LiveCode is branding itself as a product that appeals to a small niche--a subset of a subset of a subset of programmers and would-be programmers. Scaffold the climb upward, make it an easy experience, not an adventure into the arcane, and LiveCode will have a broader appeal. That's why things like super/subscript glitches in the IDE are not trivial.

Thanks again, Richard for the contribution of the plug-in. It's pretty cool. And thanks for trying to help me get my feet wet in the world of LiveCode. I hope my efforts to try to share my experience and perspective are not interpreted as hostile. Even though I think the company has had some blind-spots regarding the needs of new and light users, I want LiveCode to live long and prosper.

duanep wrote:I'm just saying, there is, or should be, an important distinction between bugs and enhancements, and customers have a right to expect menu items to perform predictably. Perfection and elegance in new or advanced features, less so. I want LiveCode to succeed.

We all do. And in general my own preferences favor yours. I'd love to see the team suspend work on new features until all current bugs have been addressed.

But unfortunately you and I don't have enough capital to pay for that. It requires a larger collective pool of licensees to cover the costs, and a good many of those truly need the new capabilities LiveCode adds with each feature release in order to deliver their apps, as much as you need Superscript and Subscript for yours.

And along the way, occasionally these introduce regressions with existing features. Sometimes even a fix in one area introduces a regression against another, which may have been what happened with the Superscript and Subscript menu items.

And beyond that, the OSes LC runs are are also in constant flux, so maintaining compatibility with new OS versions is quite a task in itself.

And so we're left with the delicate balancing act that defines all complex software projects, and the need to prioritize based on scope, severity, and opportunity.

Like I said, as you follow more bug submissions I think you'll find most are handled rather quickly. This one, for the reasons I outlined above, is just of such unusually small scope that it's taken a back seat to more pressing issues.

But still, I would encourage you to take full advantage of the technical support options included with your license and write to them to see if they may be able to reevaluate the priority for this issue.

LiveCode, to me, is something of a contradiction in terms. At the same time promising to be a language that is easy to use, intuitive, and and a rapid development environment for the "rest of us", it also assumes its customers are experienced, developer zealots who are willing and able to scale huge learning curves to get to their destination.

That description would be accurate if the current state of the Superscript and Subscript menu items were intentional. But it is not.

Let me say here a fourth time that this is a confirmed bug that everyone who's seen it would like to have fixed.

No one intends to require that LiveCode developers understand the technical details of those menu items. We all agree they should just work.

And when they were first implemented they did. Apparently a change elsewhere has since caused them to regress to their current state, where they do indeed work but only the first time they're used on a particular text run.

This will be fixed, but please understand that as important as those two menu items are to you, in all honesty I'd never come across anyone who's ever mentioned this issue before you brought it to my attention.

No one finds any bug desirable, but when we step back and look at the full scope of things we ask the team to do, it seems reasonable to expect that this bug could be at least understandable.

And looking at the big picture, this may be a question of overreach in the IDE design. Every feature in the IDE requires not only an initial cost of implementation, but an ongoing cost to maintain it. LiveCode could have simply aimed to be on par with just about every other software development toolkit in the world and never have included Superscript and Subscript menu items at all. It's nice that LC provides features normally found only in word processors or more specialized apps, but if they're causing a problem maybe aiming to be more on par with convention may not be a bad move.

But personally, I'm glad they're there, because they help draw attention to the rich capabilities of LC's multi-platform text engine. And apparently most of the few people who've used them find them working well, since as we've seen it's only subsequent uses on the same text run that make the bug evident.

So should we ditch those menu items to be more in line with other development tools and prevent this from ever being a problem in the future? Or be patient until the team can make time to address them? Or find anyone else at all in the community who also finds this important enough to spend some time submitting the fix themselves?

Personally I'd prefer either of the latter two, but any of those would be viable solutions.

I submit that LiveCode is branding itself as a product that appeals to a small niche--a subset of a subset of a subset of programmers and would-be programmers.

I don't disagree with you on that, but I do believe LiveCode is a worthwhile project.

The four most popular languages in the world are Java, C, C++, and C#. Most of the world is apparently quite content to spend their day waiting for compilers, and writing their apps a second time all over again when they want to deploy to another platform. Most of the 2.2 million apps in the iOS app store were written in Objective C, so apparently the tedium of bit-counting isn't stopping anyone from producing software with more traditional tools.

The fifth most popular language is Python, and while it's a scripting language (and quite a good one) despite massive investment from Google and others who use it, their community has nothing close to the GUI integration or multi-platform standalone packaging the much-smaller LiveCode team has delivered.

Given how people produce software today, I would agree that LiveCode at this time represents a subset of a subset of developers, those who need GUIs on multiple platforms and are willing to try something very different from what they're used to.

But I also know from firsthand experience, and from the experience of so many others throughout our community, that LiveCode does indeed offer a level of productivity in its niche that few if any other tools can match.

Will this bold experiment in revolutionizing multi-platform GUI development take the world by storm? Or will the path to get there prove as challenging as apparently other companies believe it to be, since no one else is attempting this level of GUI integration in a high-level language across as many platforms?

I don't know what the future holds. I just know that I use a few languages, monitor the scope of options for software development, and currently produce most of my software with LiveCode because it allows me to deliver what my clients need more cost-effectively than anything else available on the planet today.

Thanks again, Richard for the contribution of the plug-in. It's pretty cool.

Glad that was useful. And I do honestly believe it's a better solution for your use case than the fixed-size textShift in the IDE menu items.

And thanks for trying to help me get my feet wet in the world of LiveCode. I hope my efforts to try to share my experience and perspective are not interpreted as hostile. Even though I think the company has had some blind-spots regarding the needs of new and light users, I want LiveCode to live long and prosper.

Amen, brother. I don't think you need to worry about appearing hostile. In a sense, your posts here are a strong indicator of LiveCode's success on its journey thus far:

A small team of developers has managed to deliver a feature set beyond what nearly any other IDE provides, and apparently they've done such a good job at it that expectations are high.

Now that the project is open source, my hope is that the partnership between the company and the community can meet those expectations, and perhaps over time raise them higher still.

It's a long road ahead, but one worth traveling.