|
Daniel Pfeffer wrote: I can't imagine a worse fate
An infestation of VB6 ?
(Hope that didn't make you wet yourself in horror).
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: An infestation of VB6 ?
The end of all days is here! 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
honey the codewitch wrote: The only symbol soup i can tolerate is regex and that had to grow on me.
Yeah, like the zombie climbing fungus[^].
It makes you keep climbing up and up and up to ridiculous heights of complexity until it explodes.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Because CRLF isn't easy enough.
I blame the web.
|
|
|
|
|
If only WYSIWYG editors were smart enough, I'd agree.
But how many times have you used, say, bold in [insert WYSIWYG editor of choice], did some more editing, then as you start typing on the next line, it starts with bold because you know that internally, the bold end tag got messed up and now follows the linefeed character instead of appearing before it. That sort of thing. Bullet-point lists with various indentation levels is the other thing that gets me. Once the indentation starts getting messed up, it becomes practically impossible to fix. Copy a multi-level bullet-point list from WordPad, paste it into Word or OneNote, do some more editing, then bring it back in the original app. You're lucky if nothing got messed up.
(Multiple) decades ago, WordPerfect got it right - it was a WYSIWYG editor, but gave you a "reveal codes" option. If the editor wasn't smart enough, you at least had the ability to go in and clean things up yourself and not have to pray it eventually understands what you meant all along.
|
|
|
|
|
Never, ever, ever use bold, italic, etc. toolbar buttons to change styles.
If you want a different style, create the style, don't use the writing-to-granny-once-a-year buttons.
In dev terms: Create a class, rather than use VB-style methods.
That goes for bullets, numbered lists, etc, too (and never make a single-level list style -- go multi-level, every time, so you can just indent for the next level) It might be more work to set it up, but it saves you a shipload of hassle, and is easy to save as or export to a template.Quote: (Multiple) decades ago, WordPerfect got it right - it was a WYSIWYG editor, but gave you a "reveal codes" option
I can't think of a word processor that doesn't have that. Reveal-formatting functions are usually more convenient, because they show you precisely what the formatting is, rather than just the codes (Shift + F1 in Word; menu options in more advanced WPs).
Oh, and if you're using Word, make Normal.dot(x) read-only, unless you actually want to make changes to the template.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: Never, ever, ever use bold, italic, etc. toolbar buttons to change styles.
If you want a different style, create the style, don't use the writing-to-granny-once-a-year buttons.
Isn't that going against the very thing Marc is complaining about? If I want to put something in bold, I want a Bold button. Creating a style, as you're suggesting, is very much a developer thing and no mortal man on the street thinks in those terms or would even know what you're talking about. I'm talking about word processors and the like - not web page development tools...in which case I agree, this is what CSS is for.
Quote: (Shift + F1 in Word; menu options in more advanced WPs).
That shows you what style is currently in effect; I want precise control over where those individual styles start and finish. I've done that right now in CP's editor with 'I' tags in angled brackets. That's the sort of control I'd like to see in a WYSIWYG, if it's not going to get everything just right, all the time.
|
|
|
|
|
dandy72 wrote: I want precise control over where those individual styles start and finish
If you use styles, rather than the blunderbuss toolbar buttons, you get that. If you have to insert tags, you not only make it harder to check the text for errors, but you make it more work, and have to keep distracting yourself from the content you're trying to write, just to insert the tags.
Selecting the text to modify and clicking the required style in the Styles pane is the most efficient (and least distracting) method.
If you find you're picking up unwanted paragraph tags and spaces in Word, turn off the smart paragraph selection and select whole words options, which are stupidly on by default.
BTW, if you find that a style is going onto the next line in Word (which it shouldn't, if you select the text without picking up the paragraph character), just select the new line and hit Ctrl+Space.
dandy72 wrote: Isn't that going against the very thing Marc is complaining about?
Your preference of having to set <I></I> tags is what Marc appears not to like.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: Your preference of having to set <I></I> tags is what Marc appears not to like.
My preference is actually to not have them visible, but I do want the option to be able to view them when the editor isn't doing what I want it to do. A style viewer that shows me what style is in effect at the current location doesn't cut it - I want to see exactly where the tags start and end. In an ideal world, we'd be WYSIWYG all the way and never need to care about the underpinnings.
|
|
|
|
|
Then use a text editor and a mark-up language. The point about WySiWyG is that you can actually see when a style starts and ends -- but if you have a habit of sometimes applying styles to blankspaces, you won't know whether a leading or trailing blankspace has a style applied to it or not without selecting it and looking at the styles gallery (which should always be visible) -- unless the style coincides with one of the blunderbuss-button styles, in which case the button will be active.
Full word-processor WySiWyG, with all the options you can apply to blocks, is too complicated for a simple tagging solution, so showing all tags (which you can see in plain text by opening a FrameMaker Mif file, for example) can make a single page immensely long, and you'll have to hunt for your text -- which is one of the reasons why WordPerfect and other simple-tagging word processors sadly fell by the wayside; they couldn't add all the features that other word processors could add easily, while maintaining any kind of stability and usability.
I just remoted to one of my machines that has a Framemaker license, and can confirm that the Mif file for a one-page WySiWyG file (which is part of a 19-page document) is 29,712 lines long (and Mif files have only one blank line, with a REM character at position 1).
Even if you strip out all the Mif data that isn't actually used in the file, you're left with a pretty damned huge file, using simple tagging.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: If you want a different style, create the style, don't use the writing-to-granny-once-a-year buttons.
That doesn't solve the problem.
If you type new text immediately following bold text, the new text is bold as well. To me, that is fine. Newlines are part of the text.
If you turn bold on, type xxx <crlf>, bold off, then the <crlf> is bold and if you (later) position the cursor at the start of the new line and type yyy, that yyy is in bold. Perfectly logical.
If you turn bold on, type xxx, bold off and then <crlf>, the <crlf> is not bold and if you (later) position the cursor at the start of the new line and type yyy, that yyy is not in bold. Perfectly logical.
The only way to see that they behave differently is by the bold button being activated in the first case, not the second one, when you place the cursor at start of the second line. What more did you expect?
Now if you define a text style and apply it to the text and the newline, you are still in that style after the newline. If you apply it to the text excluding the newline, new text following the newline is not in that style. The only way see if the style is active or not, immediately following the newline, is to look at the style indications; you can't guess it from the text.
You might argue: But no text style should extend beyond a newline! Again, this is independent of bold key or style. And I would hate it: If I write four consecutive paragrphs that are to be in the same style, I would hate having to set the style at the start of each and every paragraph.
Or do you want a logic that depends on how I got to given point in the text? If I place the cursor at a given point in the text, it behaves differently from if the cursor is at exactly the same spot in exactly the same text, but that is because the character to the left of it was just inserted? Would the way of insertion matter - e.g. should past count like keyboard input or like explicitly positioning? What about an autocorrect insertion - like keyboard input, like pasting or like explicit positioning? Whatever you choose, some users will think it is illogical.
What if you made a style called BoldText, made it read only, and assigned the Ctrl-B key to toggle this style on and off, in which ways would this be better than Ctrl-B toggling bold on and off?
|
|
|
|
|
Member 7989122 wrote: Now if you define a text style and apply it to the text and the newline, you are still in that style after the newline. If you apply it to the text excluding the newline, new text following the newline is not in that style. The only way see if the style is active or not, immediately following the newline, is to look at the style indications; you can't guess it from the text.
I'm afraid you're not right, there.
If the style you use moves the text into bold, the blunderbuss Bold function behind the bold button will see that it is bold, and activate.
Member 7989122 wrote: You might argue: But no text style should extend beyond a newline!
Every word processor that I have used allows you to define the style for the line following a paragraph style, e.g. for top-level heading styles you can choose to define it as the default style ("Normal", in Word) or a sub-heading style; for a bullet style, you would almost invariably define it as the same bullet style; and for a list-header style you would define it as a bulletted or numbered style, so that it automatically starts the list after the header.
Member 7989122 wrote: keyboard input, like pasting or like explicit positioning
Keyboard input inside a block of styled text will follow that style. Most word processors will maintain source styles as the default for pasting "locally", within the same document, but apply local styles for pasting from external documents. Some word processors offer options on this.
Member 7989122 wrote: What if you made a style called BoldText, made it read only, and assigned the Ctrl-B key to toggle this style on and off
I don't recall ever seeing an option to make a style read-only (although Word goes the other way, and can be allowed to automatically "update" styles -- switch that off, for sure).
One of the main points of using styles in this way is that you have complete control, so if, for example, you wanted to change all instances of bold text to blue bold text, it takes you a few seconds to change every instance in the document. If you've used the blunderbuss bold button anywhere, the text you used it on will not turn blue (but your CTRL+B, above, will), so you will have to seek them out individually, to change their colour.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I laugh at people who want to use markdown, XML, etc. for "light" use (i.e. for less than 100,000 chunks of single-source text that need to be inserted into dozens of different documents).
PostScript is far and away the best and most usable mark-up language (markdown isn't really a real thing). I usually describe it as XML that hasn't had its balls chopped off -- but those in the know stopped using it 40 years ago, when WySiWyG editors came out, for the simple reason that mark-up languages make you spend half your time working on the infrastructure of the text, which is a HUGE distraction, when you're trying to work (imagine having to set each individual syntax-highlighting colour code for variable names, etc, when writing code, and you'll get an idea of how distracting it is).
That said, TextArea fields are adequate for things like posting messages to message boards, and don't add half an hour to page-load times; and I only ever write text for web pages in a text editor (TextPad or NotePad++).
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Now let us start a war between Postscript and TeX crusaders 
|
|
|
|
|
I'm up for it! There hasn't been a one for years!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Amen, and while you're at it, let's abandon the "command line instead of decent UIs" trend 
|
|
|
|
|
I never can get used to the number of shell aficionados who insist that for automatic operations, such as cron tasks, you must have a command line interface and a script or configuration file. How could you otherwise tell what, say, the backup system should do nightly?
If you try to argue that you could select what to do in a GUI (e.g. select which directories to back up in a directory tree presentation), activate options by check boxes, radio buttons etc. with proper labeling, help functions and menu selections of previously defined plans, and have the backup application preserve that in its internal format, these shell guys gasp: But then I have no control!
Even though they (may) admit that in theory it would be possible to manage a system the way it is usually done in a Windows environment, it would not give them the necessary control. Control is that which is exercized in 7-bit ASCII input by use of command line actions.
In my archives of computer humour, there is a printout of a long discussion on NetNews (The discussion forum in the pre-web-days) from the late 1990s: This one guy who stubbornly insisted that high level languages were useless and would soon fade away. His major argument: He wanted the VAX C compiler to compile one of his functions to exactly that one machine instruction, and there was no way he could make the compiler do that! Others pointed out that it would be silly to use that instruction in that context, but he insisted: If the compiler wouldn't do what he wanted, it was useless and should be thrown away. Assembly code is the only way to get what you want! ... This was in the 1990s, not the 1960s...
When I talk with shell guys that insists that GUIs are useless for serious work, I think that they must be close relatives to this assembler code guy.
|
|
|
|
|
Member 7989122 wrote: this assembler code guy
I think shell and console apps are useful for automation, but for serious work a GUI is intuitive, shows you what's possible and enables you to work without reading a lot of documentation.
Anyone who says GUIs are useless haven't worked with good UIs or are just pretentious jerks
And maybe some people still live in the past where GUIs weren't invented yet.
|
|
|
|
|
Can it be harder than LaTeX (did I get the stylization right?)? I remember fighting with this thing for the sole reason of everybody else doing it and brackets, which permeate scientific writing like mold are a friggin' nightmare. The escaping rules for them are less consistent than escaping in C for no good reason.
|
|
|
|
|
My wife wrote a big document with latex back then... I lost count how many times I had to jump in (without having learned latex) to get the format as she wanted and / or to fix things
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Actually, I don't mind that kind of key sequences as an input method, sort of like an extension of control characters and function keys. In an HTML editor, I wouldn't mind if two blanks followed by return would replace it with <p>[newline]<p>.
But actually, I hate HTML / XML as an input format; it is like writing a user application in x64 assembler code (with no debugger available). If you need markup/markdown, you are writing a text document. Then you should use a document editor, not documentation assembly code - whether you call it markup, markdown, Postscript, HTML, TeX or LaTeX - they are all like different document CPU instruction sets. Not document development languages.
|
|
|
|
|
Even MS seems to have lost sight of the benefits of a rapid application development (RAD) environment. In the 90s, MS created a great designer for forms in VB, and even transitioned the forms designer through conversion to assembler, then to C++.
But now, MS can't seem to hire people smart enough to make designers for XAML (Xamarin and WPF) and HTML (Blazor), and they are having trouble getting the long-existing WinForms designer to work with .NET Core.
How could developers of 25-30 years ago create such great WYSIWYG designers, but today's developers cannot?
Maybe MS and other companies that lean towards command line fuddy-duddery and hand-crafting UI are not hiring sufficiently mature and creative software engineers.
|
|
|
|
|
I thought markdown so you don't need a fancy editor to make markdown
|
|
|
|
|
Is an eating disorder when you have an order of dis, an' an order of dis, an' two of dis, an' ... ?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
And finish your meal with an order for dissert.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
