Funny enough, not exactly this, but when i review new apps - either desktop or mobile (but especially mobile!) - besides ensuring that the desired features are present and will do the trick...i try to see if i can understand where/how the files are saved...This started years ago when i was interested in exporting stuff from proprietary apps...and now i've biased myself...so whenever i can not view/access/understand how or where files are stored for an app, then i almost immediately have a negative sentiment towards said app. Sadly, for mobile apps, the obfuscation of files and how/where they're stored is too much of a prevalent thing and for me so annoying.
This started out in my quest to be sure that i can not trapped by an app, and so i can safely export my data...but, nowadays, it has extended a little into the tinfoil hat thinking - fairly or not - where i ask myself: "why does this app not disclose where its files are stored, *what do they have to hide!?!*" ...which feels like the universe is nudging me more and more towards either text-centric methods, or the simplest, open source style apps, etc. :-)
Yes, exactly, stick to the facts! Read my comment again, I haven’t said anything about the last election.
If you check the latest polls, AfD surpassed CDU (not the union CDU/CSU!).
Wow, this is really great! I've got this case very often when I need non-technical people to send me data in a JSON format, but trying to teach them what JSON is and how to edit it is impossible / takes way too much time.
This is SO close to the solution I need. If I could configure this form using typescript and then send them a link where they can't see or edit the typescript, but just fill out the form and send me the JSON, that would be incredible!!
By the way, you are including a lot of useless files and binary files in your git repository.
(.egg folder, pycache, pyc files). They make your repo very heavy.
Take a look at this example .gitignore : https://github.com/github/gitignore/blob/main/Python.gitigno...
Really? Of course you can always do things in a cleverer, more technical, less visual, better performing, "look-everyone-how-i-can-do-it" kind of way.
But I really don't get the point of your comment. It's 2022. If some people publish work that visualizes information for all of us, I'm glad they have Javascript helping them do it.
I think this somewhat misses the point. The content is clearly there. When it fails to load javascript, instead of leaving the content there, it replaces the content with a message about requiring js
The "look-everyone-how-i-can-do-it" idea is likely part of the reason that sites like this use an "app" framework. There is nothing more technical or "cleverer" about simpler websites that do not use "app" frameworks.
The issue however is not the use of an Javascript app framework (I have no issue with their use), the issue is that people falsely pronounce Javascript to be "required" and users are shown a blank page or some other ungraceful failure when they turn JS off. Clearly, JS is not required to retrieve the information, as demonstrated above. The web developer is intentionally hostile to users retrieving the information with clients (user-agents) that do not cater to advertising.
Everyone knows how easy it is to detect whether the user has Javascript enabled or not. The question is what web developers say and do when they detect it is not enabled.
That line of thinking is why you need gigabytes of RAM just to check social media, all for a few kilobytes of text. HTML and CSS already give you all the visuals you'll ever need to display a little text.
Katakana, to me, is such a trouble. I really wonder whether I'm the only one who believes that Katakana is a big part of the reason, why it's very hard for native Japanese speakers to learn English.
In a Japan of today, you grow up with a plentitude of words taken from English and written + pronounced in Katakana. So you learn to pronounce "san-do-i-chi" for sandwich, "de-za-i-na" for "designer", "su-ma-ho" for smartphone, "ca-re-n-da" for calendar. And since you use and pronounce them wrongly on a daily basis you reinforce the Japanesified pronunciations. Then, actually pronouncing "calendar" in an English way becomes tricky.
So to me, the alphabets are a great example of a "historically grown" system, that's ripe for a "refactoring".
I think this is kind of backwards. Japanese just has a restrictive phonetic system that makes it awkward to borrow English words. It’s unlikely that if it were written differently they’d pronounce the words more like English.
English has an alphabet, but we still slaughter the pronunciation of harakiri, karaoke, and kamikaze because our phonology demands it. The one Japanese word we pronounce okay is "tsunami" which has a sound we don't have, lol!
Unlikely. English and Japanese have different phonetics. The writing system just reflects the spoken language.
Korean has this same problem. Ice cream becomes ah-ee-suh kr-ee-muh, etc. I don't know very much Japanese but I believe it's even worse for Korean in this regard.
interesting perspective, but more important reason in my opinion is that Japanese has so simple pronunciation (many vowels and fewer sounds all together), so Japanese people are not accustomed to making those difficult sounds that are in English.
None of this matters because the industry relies on docx (and it's a crusty, oldschool industry so good luck changing that).
A minimum for a novel writing tool is that one can actually send the novel out in a format where your agent and editor will read it. Otherwise you're not getting that novel published.
If we're being fair, docx (or rather, tools that write docx files) offers a lot of tooling out of the box that is useful for proofreaders, editors, and typesetters. Revision history, suggestions, and non-printing comments are all incredibly useful.
> A Song of Ice and Fire was not written with Word.
When startups haven't even started up yet but are worrying about how they can scale to billion-dollar unicorn level, a common refrain on Hacker News has been "you are not Google."
Allow me to give you the fiction writers' equivalent: you are not George R.R. Martin.
You're missing the point that people are trying to make here.
Yes, it's possible to convert Markdown to a Word file, with a variety of tools. You can use Pandoc to do this if you are the sort of person who is comfortable using tools like Pandoc. I can do that, along with all sorts of other things, because I am that sort of nerd.
However, most fiction writers and editors are not that sort of nerd. Most people don't want to use Markdown in the first place. Of the people who do want to use Markdown, not all of them are that sort of nerd, either. They want an "Export to > DOCX" command in their editor, not "save the Markdown file, open your terminal app, change to your documents directory, and type "pandoc -o my-novel.docx my-novel.md". (And that's assuming they're not doing something like, well, what NovelWriter does, saving individual chapters and perhaps even individual scenes as independent files.)
Look, I love Pandoc. It's great. But it's not a tool for everyone. If someone is trying to embrace the plain text lifestyle with a tool like NovelWriter but pointing out not being able to export to a Word file is a problem for them, asking "are you comfortable with Unix command line tools" and then telling them about Pandoc if they say yes might be a great idea -- but starting out with "obviously you hate the Unix way", maybe not so much.
> you can even convert it to WordStar....magic eh? Pandoc can do that.
> (And that's assuming they're not doing something like, well, what NovelWriter does, saving individual chapters and perhaps even individual scenes as independent files.)
This is totally unrelated to the gist of this thread, but I just wanted to point out that novelWriter's project builder outputs to a single file, which can be markdown, ODF, PDF, HTML, and others. Pandoc could then make a single DOCX file out of that.
Your point still stands that this is too complicated for the average user, but I just wanted to mention this since it might make a difference for technically minded writers considering novelWriter.
That makes sense (I figured novelWriter did that, since it looks an awful lot like an attempt at a Markdown-based answer to Scrivener and that's how Scrivener's "Compile" function works), and I suspect it won't be too difficult for novelWriter to add other file formats to its exporter. So not being able to output DOCX is probably not a long-term issue, unless the maintainers have a philosophical objection to it. :)
When you too can afford to pay your editors, proofreaders, and publishers to accommodate your unique file formats and the associated changes to their workflow, you too can write in WordStar.
Since you obvious don't know what unix philosophy is, it's a md writer..that's it, you want to convert it..take a converter like pandoc. If you really think every writing program should have it's own converters..well then you end up with less interchangeable stuff. One tool for Writing another one for conversion..is that so complicated?
Has nothing todo with programming, a real hammer is better as the backside of an axe. A Specialized Knife is better then a Swiss-Pocket Knife. One tool for one job but make that job perfect.
Ever see a framer’s axe? It’s one part axe, one part hammer. It’s perfect for framers - they love it. It’s one tool which lets them chop, modify, remove nails, hammer in nails, whatever they need to do, without having to carry 4-5 different tools.
The idea that a specialized tool is always better than a multi-tasking tool is simply not true. One must only look at the popularity and utility of leatherman multi-tools to see this to be true.
Even in programming circles, one needs only to look at how many options there are for ‘ls’ to see that “one tool for one purpose” is not always the best thing.
If you have an editor, you need two way communication -- they are going to make changes in your word document, using track changes, so you also need to be able to convert back.
