Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Would something like tidyMyHorribleDcode be a solution? Put a conf file in source somewhere which states how many tabs/spaces/whatever. Before you comit code back to shared repository you run tidy to convert code to D spe format. When you checkout code from repo you run tidy with your custom settings. A great simple solution for trivial problem not worth talking about it.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Bane wrote: Would something like tidyMyHorribleDcode be a solution? Put a conf file in source somewhere which states how many tabs/spaces/whatever. Before you comit code back to shared repository you run tidy to convert code to D spe format. When you checkout code from repo you run tidy with your custom settings. A great simple solution for trivial problem not worth talking about it. So, something like indent or bcpp for Linux? http://indent.isidore-it.eu/beautify.html http://www.faqs.org/docs/Linux-HOWTO/C-C++Beautifier-HOWTO.html
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Jesse Phillips Wrote: Bane wrote: Would something like tidyMyHorribleDcode be a solution? Put a conf file in source somewhere which states how many tabs/spaces/whatever. Before you comit code back to shared repository you run tidy to convert code to D spe format. When you checkout code from repo you run tidy with your custom settings. A great simple solution for trivial problem not worth talking about it. So, something like indent or bcpp for Linux? http://indent.isidore-it.eu/beautify.html http://www.faqs.org/docs/Linux-HOWTO/C-C++Beautifier-HOWTO.html Nah, they are unworthy. Not written in D.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Bane branimir.milosavlje...@gmail.com wrote in message news:hovb6n$13s...@digitalmars.com... Would something like tidyMyHorribleDcode be a solution? Put a conf file in source somewhere which states how many tabs/spaces/whatever. Before you comit code back to shared repository you run tidy to convert code to D spe format. When you checkout code from repo you run tidy with your custom settings. A great simple solution for trivial problem not worth talking about it. It would be a start. Used by itself it would be a bit of a hassle, but having it hooked up to auto-run upon checkout/commit or upon save/load in the editor (this would ideally be better since you can double-check the reults before committing) would be pretty much what I already had in mind as a solution. Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Nick Sabalausky a...@a.a wrote in message news:hp022i$t1...@digitalmars.com... Bane branimir.milosavlje...@gmail.com wrote in message news:hovb6n$13s...@digitalmars.com... Would something like tidyMyHorribleDcode be a solution? Put a conf file in source somewhere which states how many tabs/spaces/whatever. Before you comit code back to shared repository you run tidy to convert code to D spe format. When you checkout code from repo you run tidy with your custom settings. A great simple solution for trivial problem not worth talking about it. It would be a start. Used by itself it would be a bit of a hassle, but having it hooked up to auto-run upon checkout/commit or upon save/load in the editor (this would ideally be better since you can double-check the reults before committing) would be pretty much what I already had in mind as a solution. Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language. And here's an even crazier idea: Some sort of well-thought-out UCF format (Unicode Code Format) that is like plain-text, but includes a standard metadata header (typically hidden while editing) that can help sort all this stuff out, and maybe other things as well. Obviously it would require special support from compilers and editors, but if it was well-designed (including discouragement of proprietary extensions - don't want a repeat of HTML) then I think it would be worth trying to push.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
It would be a start. Used by itself it would be a bit of a hassle, but having it hooked up to auto-run upon checkout/commit or upon save/load in the editor (this would ideally be better since you can double-check the reults before committing) would be pretty much what I already had in mind as a solution. My thinking the same. Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language. Only thing to be taken into special consideration are multi line strings. Sanitizing them would produce errors. Some kind of lexer or advanced regexpr match might be required.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
And here's an even crazier idea: Some sort of well-thought-out UCF format (Unicode Code Format) that is like plain-text, but includes a standard metadata header (typically hidden while editing) that can help sort all this stuff out, and maybe other things as well. Obviously it would require special support from compilers and editors, but if it was well-designed (including discouragement of proprietary extensions - don't want a repeat of HTML) then I think it would be worth trying to push. Sounds complicated and error prone. I still have problems with notepad and his habit of killing utf-8 files and inserting bunch of where all the nice chars were. Makes me want to kill somebody.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Bane wrote: Would something like tidyMyHorribleDcode be a solution? Put a conf file in source somewhere which states how many tabs/spaces/whatever. Before you comit code back to shared repository you run tidy to convert code to D spe format. When you checkout code from repo you run tidy with your custom settings. A great simple solution for trivial problem not worth talking about it. Uncrustify already claims to support D: http://uncrustify.sourceforge.net/ Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Nick Sabalausky wrote:
Alhough it wouldn't necessarily even need to be a full-fledged source
formatter. Just something to sanitize the whitespace between start-of-line
and anything non-whitespace would be a huge improvement *and* be
cross-language.
I think that's a great idea. Yesterday, I wrote the following program and added
it to the dmd makefile so that all checkins and installs run the source code
through it first. I welcome improvements. The current version replaces tabs with
spaces, and removes trailing whitespace.
If someone is ambitious, a full fletched D source code pretty printer would be
valuable that anyone could use, and which all Phobos source code could be run
through in order to enforce a common style.
/* Replace tabs with spaces, and remove trailing whitespace from lines.
*/
import std.file;
import std.path;
int main(string[] args)
{
foreach (f; args[1 .. $])
{
auto input = cast(char[]) std.file.read(f);
auto output = filter(input);
if (output != input)
std.file.write(f, output);
}
return 0;
}
char[] filter(char[] input)
{
char[] output;
size_t j;
int column;
for (size_t i = 0; i input.length; i++)
{
auto c = input[i];
switch (c)
{
case '\t':
while ((column 7) != 7)
{ output ~= ' ';
j++;
column++;
}
c = ' ';
column++;
break;
case '\r':
case '\n':
while (j output[j - 1] == ' ')
j--;
output = output[0 .. j];
column = 0;
break;
default:
column++;
break;
}
output ~= c;
j++;
}
while (j output[j - 1] == ' ')
j--;
return output[0 .. j];
}
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Nick Sabalausky wrote: And here's an even crazier idea: Some sort of well-thought-out UCF format (Unicode Code Format) that is like plain-text, but includes a standard metadata header (typically hidden while editing) that can help sort all this stuff out, and maybe other things as well. Obviously it would require special support from compilers and editors, but if it was well-designed (including discouragement of proprietary extensions - don't want a repeat of HTML) then I think it would be worth trying to push. Sorry, but anything that requires D users to use a custom editor for a special source code file format is doomed to failure.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Walter Bright newshou...@digitalmars.com wrote in message news:hp08a9$19l...@digitalmars.com... Nick Sabalausky wrote: And here's an even crazier idea: Some sort of well-thought-out UCF format (Unicode Code Format) that is like plain-text, but includes a standard metadata header (typically hidden while editing) that can help sort all this stuff out, and maybe other things as well. Obviously it would require special support from compilers and editors, but if it was well-designed (including discouragement of proprietary extensions - don't want a repeat of HTML) then I think it would be worth trying to push. Sorry, but anything that requires D users to use a custom editor for a special source code file format is doomed to failure. I was thinking of it as whole-programming-world kind of thing not specific to any langauge, kind of like how UTF has been replacing ASCII and code pages (although this would use UTF). Basically kind of like a programmer's RTF (although it obviously wouldn't involve setting fonts and colors, but rather things like tab settings). I agree that getting it to actually happen would be an uphill battle (especially if there's no large organization backing it :( ), but it could be worth the potential benefits if it were to happen.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Walter Bright newshou...@digitalmars.com wrote in message news:hp087r$19l...@digitalmars.com... Nick Sabalausky wrote: Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language. I think that's a great idea. Yesterday, I wrote the following program and added it to the dmd makefile so that all checkins and installs run the source code through it first. I welcome improvements. The current version replaces tabs with spaces, and removes trailing whitespace. Sounds great. If someone is ambitious, a full fletched D source code pretty printer would be valuable that anyone could use, and which all Phobos source code could be run through in order to enforce a common style. For bonus points, they could expose it as a library so editors and other tools can make use of it without shuffling everything through command-line params, stdout and the filesystem.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Nick Sabalausky Wrote: Walter Bright newshou...@digitalmars.com wrote in message news:hp087r$19l...@digitalmars.com... Nick Sabalausky wrote: Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language. I think that's a great idea. Yesterday, I wrote the following program and added it to the dmd makefile so that all checkins and installs run the source code through it first. I welcome improvements. The current version replaces tabs with spaces, and removes trailing whitespace. Sounds great. If someone is ambitious, a full fletched D source code pretty printer would be valuable that anyone could use, and which all Phobos source code could be run through in order to enforce a common style. For bonus points, they could expose it as a library so editors and other tools can make use of it without shuffling everything through command-line params, stdout and the filesystem. Will it work with multiline strings? char[] s = r I am very wide string;
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Nick Sabalausky wrote: And here's an even crazier idea: Some sort of well-thought-out UCF format (Unicode Code Format) that is like plain-text, but includes a standard metadata header (typically hidden while editing) that can help sort all this stuff out, and maybe other things as well. Obviously it would require special support from compilers and editors, but if it was well-designed (including discouragement of proprietary extensions - don't want a repeat of HTML) then I think it would be worth trying to push. You mean like the Emacs/vim headers which allow to specify everything in special comments near the top or bottom of the file and Emacs/vim sets the appropriate options automatically upon loading the file? http://www.gnu.org/software/emacs/manual/html_node/emacs/File-Variables.html Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Nick Sabalausky Wrote: I was thinking of it as whole-programming-world kind of thing not specific to any langauge, kind of like how UTF has been replacing ASCII and code pages (although this would use UTF). Basically kind of like a programmer's RTF (although it obviously wouldn't involve setting fonts and colors, but rather things like tab settings). You mean something like PTSC - http://www.synchro.net/ptsc_hdr.html
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
On Wed, 31 Mar 2010 11:49:31 -0600, Nick Sabalausky a...@a.a wrote: Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language. Crimson Editor (my preferred D text editor) has menu options to convert tabs to spaces, convert leading tabs to spaces, convert spaces to tabs, and remove trailing spaces.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
On Wed, 31 Mar 2010 21:10:22 -0600, Phil Deets pjdee...@gmail.com wrote: On Wed, 31 Mar 2010 11:49:31 -0600, Nick Sabalausky a...@a.a wrote: Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language. Crimson Editor (my preferred D text editor) has menu options to convert tabs to spaces, convert leading tabs to spaces, convert spaces to tabs, and remove trailing spaces. Correction: It has leading spaces to tabs, not leading tabs to spaces.
