NULL vs. 0 discussion
NULL vs. 0 discussion
Posted Mar 18, 2008 22:42 UTC (Tue) by zlynx (guest, #2285)In reply to: NULL vs. 0 discussion by pr1268
Parent article: Who maintains dpkg?
Indeed, style is an annoying problem. Sometimes I wish language authors would just define the space and brace layout in the language spec and make the compiler enforce it. :) Python made a big mistake in this area by allowing both tabs and spaces.
Posted Mar 18, 2008 23:07 UTC (Tue)
by dw (subscriber, #12017)
[Link] (5 responses)
Posted Mar 18, 2008 23:26 UTC (Tue)
by dark (guest, #8483)
[Link]
It's incredibly hard to do for C, though, because of the preprocessor.
Posted Mar 18, 2008 23:55 UTC (Tue)
by zlynx (guest, #2285)
[Link]
Posted Mar 19, 2008 1:32 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Mar 22, 2008 4:32 UTC (Sat)
by kevinbsmith (guest, #4778)
[Link]
Posted Mar 19, 2008 22:12 UTC (Wed)
by quotemstr (subscriber, #45331)
[Link]
(xyzzy (g|)) + DEL -> (xyzzy (|))
(xyzzy (|)) + DEL -> (xyzzy |)
(xyzzy |foo) + M-x paredit-forward-barf-sexp (normally C-left) -> (xyzzy) |foo
A fault of modern source editors?
Just a side note, but Python treats tabs as 8 spaces.
My main point is, I don't understand why we don't have "text" editors advanced enough to
preserve original whitespace style while presenting source code in the user's preferred style.
Given that source code is actually just a big data structure.
I've mentioned the idea of a "structured editor" to a few people before, and they generally
just look at me like I'm insane (which is not unusual), but other times I wonder if we had
more general purpose libraries with something like DOM APIs, would merging and source code
editing not be all the more pleasurable an experience?
Merge conflict -> "aah, statements are semantically identical"
Merge conflict -> "aah, expressions evaluate to the same type"
Merge conflict -> "aah, extra array initialiser added"
etc.
I also appreciate the idea of typing "for" and having a text editor display some sort of
widget that meant you didn't have to type the semicolons, and so on. If it was done nicely it
might greatly reduce the possibility of introducing logic errors due to typos.
In a world where source text is treated like the data structure it is by editing and merging
components, arguments about style largely disappear (although I guess naming schemes will
always come up :).
I find the concept of hand-editing a large data structure in what is basically a glorified hex
editor a little more repulsive than using a GUI to do the same job.
This is an idea that "Refactoring Browsers" try to address, but I haven't
heard of anyone trying to hook one up to a version control system to
resolve conflicts. They are usually designed the other way around: user
hits the "add parameter to function" button and the browser changes the
function and all its callers to match.
Refactoring browsers
A fault of modern source editors?
I agree with you. I'd love to have structured editor, grep, diff and patch tools.
Anything with a well-made definition should be doable, like C's BNF. Perl need not apply. :)
I would handle the preprocessor by having the editor (and other tools) handle the preprocessed
code and then replacing it with the macro in the display while retaining the macro definition
in the background. It could be expanded or contracted in the display by a double-click, or
right-click, or a little plus icon.
A fault of modern source editors?
A lot of your points have merit, but one thing you mentioned is less
useful than it might at first appear: the `code template' stuff, where you
type 'for ' and the editor types in (;;) and sticks you after the opening
bracket. This is problematical for several reasons:
Firstly, the editor is making your cursor jump around without your having
commanded it to move, and both the point it left and the place it moved to
is essentially arbitrary (does your editor's template matcher fire after
space? Bracket? Which section of the for does it move you to? Perhaps it
moves you to the loop body...)
Secondly, once you're there, there's no way the editor can automatically
tell that you've finished typing in one section and want to move to the
next, so you'll have to tell it. Had the template not been there, you
could have indicated this by pressing the semicolon; but with the template
in place, you have to hit the right cursor key some number of times, or
have a right-one-language-token key -- which is still no more convenient
than hitting ; would have been!
Everyone always uses for loops as an example of where syntactically-aware
editing would be useful, but to be honest I've never found anything more
elaborate than autoindenting and automatic closing brace/bracket insertion
to be any help at all.
Those identifier autocompletion dialogs are even worse, because unless you
have a hyper-high-end system they make the editor stall for an instant,
they tend to dump a dialog box up on top of your typing (why not open a
pane at the bottom of the screen and fill it up?) and they invariably
don't contain the identifier I'm actually *looking* for anyway. So the
result is a juddery, flickery, annoying mess, like browing an advert-laden
site with animation enabled and flash installed. :)
A fault of modern source editors?
Actually, the Java editor in eclipse has solved this pretty nicely. Type in "for" and hit
Ctrl-Space (their auto-complete trigger). Choose which kind of for loop you want, and it
creates a skeleton. It's even smart enough to look at what arrays are in scope and guess which
one you wanted to iterate over.
It places your cursor in the first "field", which is the iterator variable name ("i"). If you
modify it, all other references to i are updated to your new name. Hit tab to advance to the
second field, which is the terminating condition. Tab again gets you to the body of the if,
inside the curly braces.
Or at any point you can bail out by hitting an arrow key or mouse-clicking elsewhere. You're
not locked into just editing those fields. It takes a bit of practice, but is really quite
effective. More so for iterating collections classes and other Java-isms.
I don't really like Java, and eclipse is bloated and has a clumsy UI. But it is a really
powerful tool that manages to make programming faster and less error-prone in many ways. I
miss it when coding in other languages.
Try paredit-mode for Emacs when editing Lisp. It's a structured editing mode with commands that work on whole sexps instead of characters per se.
For example, with the cursor represented by |:
A fault of modern source editors?