> the general principle of Flutter is a terrible idea.

I think Flutter is a good idea with bad execution. Maybe due to the lack of resources or effort put into it or maybe due to the management, I don't know.

The only thing that is cross-platform right now is the web and it is based on graphics engines (Skia in the case of Chrome). My idea of Flutter is that it is being web (i.e. cross-platform) without being a browser (i.e. overhead of being browser). However, in practice, I couldn't observe a good performance from Flutter when I tried it.

Right now, a lot of apps are developed using Electron (aka Chrome). Flutter is the equivalent of Electron for mobile without the extra layer of having a browser. With the advent of frameworks using WebView (WebGPU is also becoming popular) such as Tauri, we may need less Electron and Flutter.

> Flutter Web in particular is fundamentally flawed and needs to be rebuilt from the ground up if it has any hopes of being viable tech that generates semantic, accessible, and modern web experiences.

I don't know the exact technology of Flutter Web, but I think Flutter Web doesn't makes sense because it is running a renderer (Flutter) inside a renderer (browser).

If you use VSCode as a text editor, you can use it locally on LaTeX files using LTeX extension (https://marketplace.visualstudio.com/items?itemName=valentjn...)

and if you're into Markdown, i can also recommend prosemd

https://github.com/kitten/prosemd-lsp

Good luck with listing "problem solver" as a skill in your resume. I don't think anybody will care about it.

As an experiment, one can create two resumes with different identities where the first one is listing Nim as a skill and the other one is listing Java and Spring as skills, and apply to the same jobs. I wonder what the ratio of replies will be.

If you're an actual problem solver, you don't even need a CV. Your clients will be so happy that they will recommend your services to their buddies.

Isn't org-mode tied to emacs? Also, does it have a specification? I searched for a specification and found this (https://orgmode.org/worg/dev/org-syntax.html) and couldn't understand whether it is a proper spec. Without a well-defined spec, it becomes very hard to create tooling around it. For example, Markdown was using Perl scripts initially and didn't have a spec for some time.

There's at least a parser using that as a spec at https://github.com/200ok-ch/org-parser

also this one: https://github.com/orgapp/orgajs

org-mode does not have a spec. Its Emacs implementation is the canonical implementation. But org-mode is still just plaintext, and you can read org-mode files using any plaintext editor.

Yeah but its difficult to look at and read as purely plain text, unlike markdown. And since the power-features of org arent available in your editor(s) (unless you use Emacs) it isn't tenable. I'm convinced Emacs users are blind to this given the seemless rendering done by Emacs. There's room for a new spec.

Obviously I'm biased since I built BrainTool because of my emacs/org use, but I also use markdowns and maintain the braintool.org blog on github in their markdown. I don't find it more readable. Maybe it's a familiarity thing, anything specific you dislike?

Anyway here's the definitive argument for org as markup of choice: https://karl-voit.at/2017/09/23/orgmode-as-markup-only/

It would for sure be nice to have a definitive spec to point to, independent of the emacs ecosystem.

BTW see below the first few lines of my dev-log.org file for yesterday. I think its pretty readable!

* <2022-03-30 Wed>

** DONE Today [83%]

   - [X] Call w alex

   - [X] Exercise

   - [X] instructions to Alex

   - [X] letter to Deignan

   - [X] taxes

   - [ ] styling for notes col

** DONE bug narrow edit card shows item under bullet which is confusing. :dev:099:

** DONE get rid of link in welcome topic, too confusing :dev:099:

** Instructions for running BrainTool locally:

   1) Make sure you have git installed. (https://git-scm.com/download/mac)

   2) Make a folder where you want to put the code

One of the clear problems I have with this format is that you have to write a dash in front of every todo. This may seem like a minor gripe, but when writing todos is by far the most common action, it really does increase the friction a lot.

That's still too many formatting bits for me.

My weekly todos look something like this:

It uses a simialr format:

YYYYMMDD

- Task to be done

  - Subtask

  * Note about task

/ Task started/half done

x Task completed

ie:

20220328

- finish baselining instances for ami creation

  x server 1

  / server 2

  - server 3

   * Make sure RH image is being used vs AWS provided AMI

/ verify routes exist for all subnets

x snapshot instance X before users are added

-- Dave

You can have YYMMDD too.. its just how he's input it.

IMHO: Workflow, Text input fields and File formats are like APIs; if there is a way to abuse, hidden or public, then someone will use that in their process (https://xkcd.com/1172/). So adhering to Org mode in your own parser will mean a lot of work anyway. There will always be some subtle point that make your format incompatible with a tool you want to use.

Is it really that much harder to read than Markdown?

- Headings: Markdown uses #, Org uses asterisks.

- Italic: Markdown uses asterisks or underscores, Org uses /

- Bold: Markdown uses double asteriskes, Org uses asterisks

- Inline Code: Markdown uses backticks, Org uses =

- List items: both use dashes

- Links: Markdown uses [description](url), Org uses [[url][description]]

- Code blocks: Markdown indents each line by four spaces, or some modern dialects use tripe backquotes, Org uses #+begin_src, #+end_src tags

Sibling comment already addressed the readability of the source, but I'd like to ask what rendering you mean exactly?

The "rendering" I see in an open org-mode file right now is a) coloring and b) collapsing. So apart from hiding and coloring things I think what emacs shows is exactly the source, at least in my configuration. Did I miss something?

When I last played with it (Emacs + Org) I had options enabled which hid much of the markup entirely (e.g. the **) and applied various styles to express the intended structure, and it was lovely, much more than just coloring. Nothing I'm saying is without love for Emacs and Org, more just sulky acceptance that tools can add additional mental overhead, even if they're cool, and this seems to be the opinion/philosophy of modern tools etc, VSCode/IDEs/Web-based IDEs etc.

So.... when I tried to use Org in VSCode, Vim, Notepad etc, it just sucked. Not even a comparison. In that case, Markdown was better. Maybe I'll look at it again. But like the OP (in the sense of making up my own thing) I have dabbled in creating my own clone of Org-mode based on a Markdown spec.

Hmm ok, I never have these options on. For no particular reasons other than that they don't seem to be the default (or something's wrong with my config), and I never missed any additional application of style.

So it's possible that I just got very much used to how org-mode "source" looks.

Yes, for task management and for any other applications, Emacs offers programmable views of Org files.

A popular view of Org files that comes already builtin in Emacs is the agenda view.

The agenda view lets you query all todos, incoming deadlines, scheduled appointments, etc. harvested from a list of Org files.

For example, I can quickly see all todos, incoming deadlines, scheduled appointments, holidays etc. for an arbitrary period of time, say week 40 of 2022.

Yeah, but this was about comparing markdown and org-mode (for readability and probably visual appeal), and rendering the "raw" buffer.

You can get quite far with it. I’ve used https://orgmode.org/worg/dev/org-syntax.html when implementing lots of https://plainorg.com and https://flathabits.com.

Last time I checked, there was an extension for org-mode in Visual Studio Code, but it felt a bit more like a glorified WSIWYG markdown editor with a few extra features - just a tiny, tiny fraction of org-mode's potential. But that tiny fraction alone covers a wide variety of use cases.

There are implementations for other editors, for example NeoVim[1].

[1] https://github.com/nvim-orgmode/orgmode

Yet, companies use AST tools, which automatically processes the CVs and resumes.

One person that is developing such a tool recommended collage students not to add too much links to their CVs because otherwise, their CV will be flagged as a malicious document.