For devs: the new "delegated" label

[Edward K. Ream]

This page shows 6 open items that I have delegated to others.

Devs, please do your work in separate branches.

Imo, none of these should delay Leo 6.1 b1, coming fairly soon, perhaps next Friday.

Edward

[vitalije]

Regarding #490 I think that I made my position clear: the support for font settings per language should be removed. OTOH, Edward you explicitly wrote:

 I'm concerned about removing settings. How do you propose to allow per-language settings?

I propse to remove per-language settings. Whoever uses this settings can't use Ctrl-<wheel> zoom. I am almost sure nobody uses those settings and in leoSettings.leo there are just settings for php and forth. So, anyone who uses Leo to edit php files suffers from this bug. If there is anyone who uses Leo to write in forth language, the same bug bites again.

The only reasonable solution (IMHO) is to drop the support for font settings per language. Or at least to remove those settings from leoSettings.leo. In that case issue 490 will go away for PHP programmers, but we'll be waiting for someone else to try to customize font per language according to the official documentation, and then to report the same issue again. I think Terry was the one who wrote the code that allows Ctrl-wheel zoom and it seems to me that fixing this code to honor font-per-language settings will be very difficult and most likely will hurt the overall performance. The code would have to look up all per language font settings and to change them on every zoom in/out (number of languages Leo supports  x  number of possible font settings[1,2,3,4] x font[family, weight, slant, size]). It is something not very like worth doing.

If you still want to delegate this issue to me, I will remove the support for font per language setting. 

Vitalije

[Edward K. Ream]

On Sat, Sep 28, 2019 at 6:54 AM vitalije <vita...@gmail.com> wrote:

Regarding #490 I think that I made my position clear: the support for font settings per language should be removed. OTOH, Edward you explicitly wrote:

 I'm concerned about removing settings. How do you propose to allow per-language settings?

I propose to remove per-language settings. Whoever uses this settings can't use Ctrl-<wheel> zoom. I am almost sure nobody uses those settings and in leoSettings.leo there are just settings for php and forth.

How can you be sure that nobody uses those settings?  The settings were put there as the result of specific requests. Lot's of people may use Leo to edit .php files. They may not be reading Leo's forums, and yet they could still be using those settings.

So, anyone who uses Leo to edit php files suffers from this bug. If there is anyone who uses Leo to write in forth language, the same bug bites again.

I see.

The only reasonable solution (IMHO) is to drop the support for font settings per language. Or at least to remove those settings from leoSettings.leo. In that case issue 490 will go away for PHP programmers, but we'll be waiting for someone else to try to customize font per language according to the official documentation, and then to report the same issue again. I think Terry was the one who wrote the code that allows Ctrl-wheel zoom and it seems to me that fixing this code to honor font-per-language settings will be very difficult and most likely will hurt the overall performance.

Thanks for this history.

 

The code would have to look up all per language font settings and to change them on every zoom in/out (number of languages Leo supports  x  number of possible font settings[1,2,3,4] x font[family, weight, slant, size]). It is something not very like worth doing.

Zooms happen rarely.  Imo, it would be best to keep the present settings, and do the work of supporting them when zooming.  Zooming might then take an extra millisecond or so.  Imo, keeping existing settings is far more important than saving this time.

If you still want to delegate this issue to me, I will remove the support for font per language setting. 

I would still like to delegate this to you. If you are willing, please investigate having zooms support all related settings.

Edward

[vitalije]

On Sunday, September 29, 2019 at 12:43:57 PM UTC+2, Edward K. Ream wrote:

 The settings were put there as the result of specific requests.

I am not very convinced that is the case. I think they sometimes are put just because you or any other developer thought they might be useful. For example, I just published new plugin. Nobody asked me for this. I put it there because I thought it might be useful to someone. I might be wrong as well. I was thinking of putting new settings like: `@string history-tracer-file-list`, `@string history-tracer-executable` and `@int history-tracer-port`. In the end I decided to only use the last one. Nobody asked for any of them. It was just my guess that they might be useful. I believe there were many similar examples in Leo's history.

 

Lot's of people may use Leo to edit .php files. They may not be reading Leo's forums, and yet they could still be using those settings.

 

I would still like to delegate this to you. If you are willing, please investigate having zooms support all related settings.

Edward

 

I remember that I have tried two or more times in the past to fix this issue. I don't remember very well the details but I do remember that I bumped every time in the roadblock which required some very ugly hacks and I abandoned it every time with the strong feeling that nobody really uses this feature, and even if someone does use this feature, it is very hard for me to understand why? What would anyone get through this feature. I really doubt that other editors have similar feature. 

If I ever get really bored and in need of some detective investigation work, I might try to solve it just for sport. But it is highly unlikely to happen. If some user shows up with a very good explanation why this feature might be necessary, I would reconsider putting an effort to solve this issue again. As I said before, I am pretty sure nobody uses this feature. If they did, this issue would be reported many times by now. 

In effect, a viable feature like (Ctrl+wheel zoom), which is supported by almost every application today, is currently broken in Leo, and the only reason it is broken is some leftover settings in official leoSettings.leo and a few paragraphs somewhere in the Leo's documentation. Your decision to support some potential users who might be still using this feature goes against many actual users (and especially new users) who are using zoom and writes programs in PHP.  Why wouldn't you rather have more compassion to those real users, than to some potentially existing users? Let's remove this feature and wait to see if someone is going to notice that it is missing and report an issue.

By the way, in one of your recent commits you wrote:

 Removed *weird* redundant, non-functional code in at.precheck

That removal  made my Leo totally broken. When I finished my new plugin and wished to push it, I had to update my repository. When I opened leoPlugins.leo after update, and added my plugin there, I could not write the external file. Leo persistently reported that my file is not written because of errors, but no other explanation was given. I checked and rechecked several times looking for some orphan node or anything similar but there was no obvious reason why Leo should refuse to write this file. I had to run it in debugger, step by step, to find that my file is not written because the path it should be written is not equal to the path from which it was read. However, no such explanation was given, nor I as a user was asked if I am sure that path is correct and that the file should be saved to the new path. The problem was in my using symlinks. The both paths resolve to the same file, but they are different if compared as strings. This change is most likely connected with your recent changes of g.os_path_... methods for security reasons. I believe you removed this "*weird* redundant, non-functional code in at.precheck" because recently Leo started to ask too often for permission to write file with no obvious reason. I think I had noticed that too, but didn't pay too much attention. I've fixed this issue and it also fixed issue: #1282 at the same time. 

My point is: you are sometimes too careful not to make an inconvenience to some unknown invisible group of users (who might as well be nonexistent), and at the same time (unintentionally of course) you brake some of the Leo's elementary functions for real visible users. I really don't blame you for this. It could easily happen to anyone. But what if it happen? We survived it. It was an inconvenience but nothing too dramatic. Then why not take a risk and make some small inconvenience to those invisible and perhaps only fictional users in order to make something work for the real and visible ones? If they are not fictional, they will raise their voices and we will know they exist. After all Leo is distributed under MIT license which explicitly states:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

 

And yet you act like there is a bunch of lawyers at your doorstep ready to sue you if you dare to remove some ancient feature that is:

• broken for years now,
• and there were no complains about it being broken

The only complain we have so far is from a user who doesn't use this feature (font per language setting), but the feature he uses is broken (Ctrl-wheel zoom). Why not respect this one user whose complain is sound and reasonable?

Vitalije

[Edward K. Ream]

On Sun, Sep 29, 2019 at 9:51 AM vitalije <vita...@gmail.com> wrote:

> I am not very convinced that is the case. I think they sometimes are put just because you or any other developer thought they might be useful.

In this case there was a specific request from a user.

> I remember that I have tried two or more times in the past to fix this issue. I don't remember very well the details but I do remember that I bumped every time in the roadblock which required some very ugly hacks.

I'll look into this. We are past the point were additional explanations would be useful.

Edward

[vitalije]

On Monday, September 30, 2019 at 6:56:00 PM UTC+2, Edward K. Ream wrote:

I'll look into this. We are past the point were additional explanations would be useful.

Edward

I'm impressed with your fix. It seems so easy, now that I saw it. 

I do apologize for all the fuss I have made about it, I was wrong.

Vitalije

 

[Edward K. Ream]

On Wed, Oct 2, 2019 at 1:40 AM vitalije <vita...@gmail.com> wrote:

I'm impressed with your fix. It seems so easy, now that I saw it. 

Thanks.

I do apologize for all the fuss I have made about it, I was wrong.

No apology needed. I wouldn't have taken the issue seriously without you.

Edward