nedit-ng
nedit-ng copied to clipboard
eteran
Support for .editorconfig
.editorconfig is quickly emerging as a well-supported standard for setting directory tree editor settings. Supporting this should be easy enough since they offer a pretty simple Qt implementation. And it seems reasonably that it would take precedence over existing editor settings.
https://github.com/editorconfig/editorconfig-core-qt
I have not spent too much time to dig into it, but it seems to exist as plugin for those editing already supporting it. NEdit does not has a plugin support, so we need to make one?
I'd like for NEdit to eventually have plugin support. But honestly, this feature is simple enough that I don't think it would be overkill to just have it built-in.
The example Qt implementation to fetch the settings is less than 500 lines of formatted and commented code. In a single cpp/h pair.
Just wondering, is this going to be a completely new feature, or in some way replace/enhance some functionality in nedit 5?
Right now, I envision it as a new feature, that would by default take precedence over NEdit's existing language settings (for the application setting).
There would be an option in config.ini to say "enableEditorConfig" that would by default be true, but if a user REALLY prefers to use their settings over the ones specified by the project, then they can set it to false.
Honestly, if I were not concerned about backward compatibility at all, I'd just remove things like tabs and indent rules from nedit's language definitions and just say "use .editorconfig instead"... But I feel that would be a bit too aggressive.
So for now, my thought is, "use .editorconfig if it's there (by default), but if it isn't, we'll just fall back on the existing relevant language settings".
Frankly, .editorconfig's specification is more robust than NEdit's. It uses globbing on the filenames instead of just extensions, which lets it more easily target things like Makefile.linux .
Without this is really making it difficult to edit nedit-ng with itself.
While I'm here, can we please change hard tabs to expand to 4, as is per unix standard; or, standardize on spaces and no hard tabs? Other tools assume tab=8 and 4 just never works for mixed space/tab formatting.
I think the best way is to support .editorconfig on a per-file basis. I adjust the per-window preference (without messing with the default ones) all the time - editing a large codebase that doesn't use .editorconfig.
PPS: Any .editor shouldn't take over the saved default settings*. Override the per-window settings when loaded. That way you have a hierarchy of it.
*except with perhaps the special case of when there are none, when starting from scratch
Without this is really making it difficult to edit nedit-ng with itself.
While I'm here, can we please change hard tabs to expand to 4, as is per unix standard; or, standardize on spaces and no hard tabs? Other tools assume tab=8 and 4 just never works for mixed space/tab formatting.
I'm not sure what you mean here. I believe that I use tabs for indentation (spaces for vertical alignment) and you can certainly set NG to use 4 wide hard tabs which is what I have done.
I think the best way is to support .editorconfig on a per-file basis. I adjust the per-window preference (without messing with the default ones) all the time - editing a large codebase that doesn't use .editorconfig.
Absolutely, that's basically what I meant above (if I understand you correctly).
For it will not effect the built in settings and will simply take precedence over the per tab language settings.
Hi, just a fairly dumb comment here - I'm guessing @sjtringali meant that NG defaults to expand a hard tab to 8 spaces, until you change it in the Default Settings, and NG source has hard tabs. I confess I bumbled along looking at NG source code for a while, using NG, thinking "this 8 space indenting is sure hard on the eyes", until I thought to check for hard tabs, and change it. Mine is at 3 now. I'm not used to hard Tabs in files now, it didn't cross my mind to check it. So a default of 4 to expand hard tabs would be less surprise for many people.
I have been thinking I should change the default to 4 for a while!
The only reason I haven't is because classic defaulted to 8... But you're right, might be time to change that!
Yeah, I don't think 8 spacing is very common now. In fact I'm not sure why it ever was. A bit of Googling ..
https://superuser.com/questions/355863/why-is-the-default-tab-size-8-spaces-where-does-this-come-from-and-why-is-it-th
https://en.wikipedia.org/wiki/Tab_key
Looks like it actually comes from typewriters and old line printers / telprinters. There's so much stuff comes from those days, like the Ascii DEL character is 0x7F, ie. all 1's, so you can punch out all the holes on a paper tape and DELete the character. Now we try to use it as a Forward Delete mostly. But that makes no sense on a mechanical teleprinter. But Backspace made sense, you could back up and then overstrike characters. So all that was easy. Anything could be underlined with underscores. "Y" + "-" = Yen character. Ah the good old days. But ok there's only so much you can create with overstrikes.
4, as is per unix standard
@sjtringali The Posix standard width for hard tabs is 8 spaces, not 4:
-t tablist Specify the tab stops. The application shall ensure that the argument tablist consists of either a single positive decimal integer or a list of tabstops. If a single number is given, tabs shall be set that number of column positions apart instead of the default 8.
Many of the projects I have to work on have source code dating back to the 90s and still have hard tabs in them followed by 4 spaces where necessary for 4-space alignment. I have been replacing the tabs with spaces as I work on and reformat those files, but many will probably never get fixed. Please don't change the current default, just implement support for the .editorconfig file...
@anjohnson some good points. DO keep in mind that that the default is just a default, that default will ALWAYS be able to be adjusted application-wide no matter what happens.
The only thing that even potentially changes for anyone is that people who prefer 4 over 8 will get what they want after a fresh install and people who prefer 8 over 4 would have to adjust the global settings after a fresh install.
But nothing has been decided yet.
My preference so far is to implement .editorconfig and see where we go from there :-)
@anjohnson some good points. DO keep in mind that that the default is just a default, that default will ALWAYS be able to be adjusted application-wide no matter what happens.
While having the ability to let user adjust is certainly a good thing, we still need to make sure the defaults are the most sensible ones, in order to minimize the needs to have to do that.
I prefer 4 but don’t really care. It’s hard tabs I find unworkable in a team environment, it always looks broken in web based diff tools.
On Dec 28, 2020, at 3:17 PM, Evan Teran [email protected] wrote:
@anjohnson some good points. DO keep in mind that that the default is just a default, that default will ALWAYS be able to be adjusted application-wide no matter what happens.
The only thing that even potentially changes for anyone is that people who prefer 4 over 8 will get what they want after a fresh install and people who prefer 8 over 4 would have to adjust the global settings after a fresh install.
But nothing has been decided yet.
My preference so far is to implement .editorconfig and see where we go from there :-)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
4 is a Windows thing. I’ve never seen it in any Unix.
Hard tabs are essentially lossy compression. It’s the JPG of source code with quality level=1.
On Dec 28, 2020, at 1:05 PM, Andrew Johnson [email protected] wrote:
4, as is per unix standard
@sjtringali The Posix standard width for hard tabs is 8 spaces, not 4:
-t tablist Specify the tab stops. The application shall ensure that the argument tablist consists of either a single positive decimal integer or a list of tabstops. If a single number is given, tabs shall be set that number of column positions apart instead of the default 8.
Many of the projects I have to work on have source code dating back to the 90s and still have hard tabs in them followed by 4 spaces where necessary for 4-space alignment. I have been replacing the tabs with spaces as I work on and reformat those files, but many will probably never get fixed. Please don't change the current default, just implement support for the .editorconfig file...
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
😢
@sjtringali sorry to hear that you dislike hard tabs so much. I can't say that I agree with your assessment, but fortunately GitHub respects .editorconfig and will show hard tabs as 4 wide 😜.
I'm not really a fan of indenting with spaces, mostly because of issues regarding editors either assuming groups of spaces are a virtual tab to remove when I want to just remove one space, or forgetting that a group is a virtual tab forcing me to manually delete the spaces one at a time.
Inevitably, it does the wrong thing for me at some point.
That being said, if it makes it any easier, you can always code using your preferred format and then use clang-format since there's a config file for my preferences in the repo...
for the record, I am not a big fan of hard tabs either. They used to be helpful when disk space were expensive, but perhaps it's time they retired. LOL
@tksoh for me, it's not about saving space. Frankly, I'm not sure there have ever been enough tabs in a typical source file that it served as a useful compression metric, at least not in my lifetime :-P.
it's just that in my mind, an "indent" is a tab so that's what I want to type. If it were possible to use spaces with none of the drawbacks I experience, then sure, I'd be all over using spaces.
But alas both choices have some downsides, which is why people have different preferences :-).
Tab-indentation is an art, everybody see it in a different way. In the best interest of transitioning to NG, I'd say we should just maintain the same behavior for now, just like the other features. We can save the debate for another day ;-)
@eteran just wondering... if two projects both coded in same language, say C++, but one use 4-space tab, the other using 8-space. Can .editconfig handle this?
Absolutely, it supports per file pattern settings within the project.
So you can say that *.cpp uses 8 space tabs, while *.py uses 4 space emulates tabs, etc...
That's great. Maybe you can start a branch to add this in, so we can try it out earlier in preparation for 6.1 :-)