kaushalmodi

I'm getting a 404 here: https://blot.im/guides

That author has a coding blog.. he might as well switch to something real like https://gohugo.io.

Try it :) For me, Ctrl+S on Chrome on most sites hangs up the browser for few seconds, even into minutes before it shows the File Save popup. And most of the times, I do Ctrl+S by mistake out of habit has that binding is for searching in Emacs.

Not sure why Chrome takes minutes to present the File Save popup, but that action is instant on Firefox.

Ever hit Ctrl+S on sites like Gmail or Inbox on Chrome?

Umm, dice rolling is in serial order in Settlers, but everyone has to pay attention in each turn.

And any one can get a come back at any time. Hasn't this ever happened to you? You get a lot of sheep/wool, you build a 2:1 sheep port, and exchange all the sheep for stone, etc to upgrade to cities, and so on?

> notification .. Jekyll rebuilds

I chuckled, I use Hugo :)

By the time I save my post and glance towards the browser in other monitor, rebuilding has already finished, and the browser live reload has already displayed the updated post.

From what I have seen, Hugo themes are a combination of visual makeover plus some even requiring a certain structure of site content. Here's an example theme DocDock[1] that is not just a blog made to look like something else.

Again, YMMW.

[1]: https://themes.gohugo.io/theme/docdock/content-organisation/

Have you set up a Hackernews/Reddit crawler that pings you each time someone mentions "ripgrep"? Seriously, I'd be interested in knowing what solution you use.

Of course, "also" means "in addition". I was wondering what I'd do with helm-dash on GNU/Linux if Dash is only for Mac.

The helm-dash repo tagline on GitHub says "Browse Dash docsets inside emacs", so I quickly dismissed it as I don't use Mac.

Reading a bit further, now I see that it doesn't need Dash to be installed. So that's great! I'll see if an ivy/counsel version is out there.

But isn't Dash just for Mac?

Once you get confident with your static site generator, you don't even have to download it or run it locally (not kidding).

I have my Hugo-based blog on Gitlab (content, themes, config, etc).

I just need to commit changes to my plain text content (Org/Markdown) -> Netlify sees the commit -> Runs hugo to generate the site -> Site gets published.

Have you looked at the Hugo themes and the tags on the right side?

Here are themes tagged Portfolio: https://themes.gohugo.io/tags/portfolio/

I actually find many themes that are non-blog based in there.

Is this what you mean:

I write my blog posts in Org mode. So I wrote this package ox-hugo that exports that to Markdown + the front-matter required by Hugo, in the folder structure for Hugo.

Now I just write in normal Org, and don't worry about manually setting up the post front-matter -- https://ox-hugo.scripter.co

(That site is generated by ox-hugo + Hugo btw :))

Here's the official form of Joseph's writing project that supports Org mode: https://github.com/kaushalmodi/writing-org

Live site: https://org.scripter.co

I got the below Org syntax to work so far.. You can try by copying the test file I have so far ( https://raw.githubusercontent.com/kaushalmodi/writing-org/ma... ) and pasting in the above live site.

Pasting the same below just for reference.

    * Heading level 1
    ** Heading level 2
    *** Heading level 3

    Paragraphs get created
    only after an empty line.

    This will be a new paragraph.

    * List syntax is the same as Markdown

    - List 1
    - List 2

    asdf (*!bug!* non-list breaker text should not be needed. Two empty lines should end a list.)

    1. Ordered
    2. Ordered

    *!bug!* No white-space following an ordered list.

    * Inline Code

    =code=

    == =code= ==

    == abc = def ==
    * Bold
    *bold*
    *bold * asdf*
    - Press =Ctrl+B= to toggle bold.
    * Italics
    /italics / adsf/
    - Press =Ctrl+I= to toggle italics.
    * Horizontal rule
    Above the horizontal rule
    -----
    Below the horizontal rule

    * Source blocks
    #+BEGIN_SRC emacs-lisp
    (message "foo")
    #+END_SRC

I have begun my frail attempt at supporting Org mode here[1]. Calling it frail because I am relying only on my search/replace and regular-expression skills. I don't know Javascript. So JS experts, please help out if you can.

[1]: https://github.com/kaushalmodi/writing/tree/org-mode

Very cool! It would be nice to see an Org mode version of this.

Org syntax for the uninitiated: http://orgmode.org/worg/dev/org-syntax.html

It's very similar to Markdown if using Org just as a markup.

---

Can folks interested in Org mode support please upvote this issue: https://github.com/josephernest/writing/issues/13

If nothing else, it will at least help somewhat guage the interest in Org mode :)

I do pretty much that using GNU Stow. Of course I then build packages and libraries on my own, in my $HOME, because I don't have root access on that machine.

I install any PACKAGE of version VERSION in:

    ~/stow/pkgs/PACKAGE/VERSION/

So taking nim for example, I'd have:

    ~/stow/pkgs/nim/0.17.1/

Under that, I'd have the whole FHS system for just nim 0.17.1:

    ~/stow/pkgs/nim/0.17.1/bin/
    ~/stow/pkgs/nim/0.17.1/lib/
    ~/stow/pkgs/nim/0.17.1/share/

I set ~/stowed/ as my STOW_TARGET. So on running stow, symlinks to all:

    ~/stow/pkgs/PACKAGE/VERSION/{bin,lib,share,..}/..

get created in:

    ~/stowed/{bin,lib,share,..}/..

I then have aliases set up to do something like "unstow PKG/OLD_VER" and "restow PKG/NEW_VER" when I want to change the package version.

I skip the "restow" step if I just want to "soft uninstall" a package i.e. remove it from PATH, PKG_CONFIG_PATH, MAN_PATH, .. by removing it only from the STOW_TARGET ~/stowed.

"Hard uninstall" would be simply:

    \rm -rf ~/stow/pkgs/PACKAGE/VERSION_I_DONT_WANT/

Or even:

    \rm -rf ~/stow/pkgs/PACKAGE_I_DONT_WANT/

Thanks. That's good to know, though it's impossible for rg to do something like this at the moment.. highlight different regexes in different colors. Note that support of \K from PCRE is really crucial for this.

    # Do "ack2 --help" to learn more (or "ack2 --man" to learn even more).
    alias ack_passthru '\ack2 -h --flush --passthru --color \!:*'

    # USAGE: SIM_COMMAND | hllog
    alias hllog "ack_passthru   --color-match='white on_red'   '(\*[FE],\w+):' \\
                 | ack_passthru --color-match='white on_red'   '^(Error-\[.*?\].*)' \\
                 | ack_passthru --color-match='white on_red'   '(\*[FE],\w+)\b.*?([a-zA-Z_.0-9]+),(\d+)|\d+' \\
                 | ack_passthru --color-match='white on_red'   '^FOO Info\s+::\s+\K([1-9][0-9]* Runs (Failed|Missing))' \\
                 | ack_passthru --color-match='red'            '^UVM_[EF][ROATL]+\s+:\s+[1-9][0-9]*' \\
                 | ack_passthru --color-match='black on_white' '(\*W,\w+):' \\
                 | ack_passthru --color-match='black on_white' '(\*W,\w+)\b.*?([a-zA-Z_.0-9]+),(\d+)|\d+' \\
                 | ack_passthru --color-match='black on_white' '^(Warning-\[.*?\].*)' \\
                 | ack_passthru --color-match='yellow'         '^UVM_WARNING\s+:\s+[1-9][0-9]*' \\
                 | ack_passthru --color-match='yellow'         '^FOO Info\s+::\s+\K([1-9][0-9]* Runs with Warnings)' \\
                 | ack_passthru --color-match='yellow'         '^(FOO Warning\s+::.*)' \\
                 | ack_passthru --color-match='white on_red'   '^(FOO Error)\s+::' \\
                 | ack_passthru --color-match='white on_red'   '^(FOO Fatal)\s+::' \\
                 | ack_passthru --color-match='yellow'         '^(\*WARNING\*[, ].*)' \\
                 | ack_passthru --color-match='white on_red'   '^(\*ERROR\*)' \\
                 | ack_passthru --color-match='white on_red'   '^\s*(ERROR:)' \\
                 | ack_passthru --color-match='white on_red'   '^:\s*(ERROR:.*)' \\
                 | ack_passthru --color-match='red'            '^:\s*(FAILURE:.*)' \\
                 | ack_passthru --color-match='yellow'         '^:\s*((WARNING|LIMITATION):.*)' \\
                "

ack still shines when I have a unique application to highlight one or more regex expressions in a log file because of its unique `--passthru` option, AND support of PCRE regex.

So I can have regex like 'abc\K(def)(?=ghi)'. That will highlight ONLY 'def' in the text but only if that string is preceeded by 'abc' and 'ghi' follows.

- ripgrep cannot do that as it does not support PCRE

ag support --passthrough, but I haven't yet felt the need to try that as ack --passthru has been baked into my workflow and aliases for ages.

I use ripgrep (rg) otherwise by default.

> if it's a good plaintext markup language, why would we concern about an editor anyway?

I work with a colleague who edits Org mode files in Vim just fine. But if you use Emacs to edit the same file, you get the benefits of subtree folding, syntax highlighting, etc.

You can get the same in Vim too, but someone has to develop a plugin for that.

So talking about my colleague editing Org mode in Vim, once he is done editing, he runs a Makefile that runs emacs in batch mode to run the Org exporter.

> TBH the time it's being useful is when I am writing in _any_ plaintext editor.

You still can, as I mentioned above.

The benefit of plain text is that it can be easily edited in any editor. Now emacs just adds features related to viewing (folding, syntax highlighting) and navigating on top of that. Given time and enough interest, any editor can support those features for Org mode files.

Static site generator (Hugo) plus my ox-hugo (Emacs/Org mode) plugin allows creating this whole site[0] from a single content file :)

[0]: https://ox-hugo.netlify.com

+1 for Netlify. I've had 2 complicated customer service questions, and they resolved them brilliantly. I am using the free tier.

I use Hugo for my static sites:

- https://scripter.co - https://ox-hugo.netlify.com - https://ox-hugo.netlify.com/test (yes, that's a different Hugo site than above)

To be honest, Markdown feels simpler because it's quite less featured than Org.

If you put a Markdown document and an Org document implementing only what Markdown can, there's no readability difference between the two as I know both markup style fairly well.

> org-mode does indeed support footnotes[fn:1], but I was recently saddened to find that Github doesn't render them (it does render more basic org-mode features, though).

GitHub uses this org-ruby project[1] to render Org files. If someone loves Org and knows Ruby too (I don't), please open PR's on that repo to improve Org parsing.

[1]: https://github.com/wallyqs/org-ruby

Thank you. Please try it out and open as many issues as you can. I'd like "ox-hugo" to just work for others as it has for me.

> Further balkanization of the export behavior isn't an advantage!

I'm not sure I understand that. You need to customize the export behavior because everyone doesn't prefer the exact same thing. While you prefer not to auto-convert to en/em-dashes, I prefer that. So having options (what you refer to as balkanization) is good.

> Comparisons to the minor incompatibilities of Markdown parsers is laughable

Didn't follow that. What incompatibility is this in reference to? Which parser? Of which flavor of Markdown?

> when the solution to concerns about the format is "customize your local Emacs."

How else would every user get their export behavior unless customizability is added? Taking the same example as yours, I am glad that "--" does the job of "–" or "–".

I know of one Markdown parser (Blackfriday) that adds a similar en-dash/em-dash conversation like Org exporter (and is enabled by default in Hugo). So the customization is needed by a sizeable number of people.

In the end, it's alright if you don't prefer Org mode or like the option to have options. I presented the ox-hugo package for folks who like blogging using Hugo, but don't want the leave the comforts of Org mode. I am not enforcing Org mode on anyone.

As everything else, that can be disabled too. Org mode/Emacs is immensely configurable. See http://orgmode.org/manual/Special-symbols.html and `org-export-with-special-strings` in http://orgmode.org/manual/Export-settings.html#Export-settin...

> Sure it does, <!-- ... -->. This is also what Emacs will automatically use if you add-file-local-variable in a Markdown file, so I don't know why you're using that weird format.

I was thinking of native comment syntax in Markdown, which is absent. But you are right, HTML comments, like anything else HTML work fine in Markdown. So you have a valid point.

> There's a stronger argument to made that org-mode doesn't really have comments. As far as I can tell syntax-ppss never gives me non-nil for them.

Hmm, I had never checked that. That's good to know. M-x comment-dwim works though. This might be good to report as Emacs bug.

> Sure, a line like "# foo" appears in a comment face,

That's a proper comment as per Org spec. Those lines are completely ignored by Org, for any parsing or for any exporting business.

> but so does a line like "#+ASDF:" or "#+BEGIN_SRC" (but not a line like "#+TITLE:").

Because those are not comments. It's not an official term but I think of those as pseudo-comments. The "#+.." lines while looking like comments have a special meaning to Org. The meaning of those can also be exporter backend dependent.

> So whether something is a "comment" depends on its contents, which means it's syntax, never really a comment.

Yes only for #+ comments.

Of course I am aware of that :)

I did my "market study" before I started investing time for this project. I have a page on ox-hugo Documentation site (the first link in my original comment) that talks in detail why I needed to have a ox-hugo: https://ox-hugo.netlify.com/doc/why-ox-hugo/

> your markup without the blank lines and

That's because I like that and only I am using that.

If it's a matter of team collaboration, certain ground rules can be set to resolve that.. like use blank lines after headings. You might be surprised but there's actually an Org mode setting in Emacs which can be configured to set how many blank lines to auto-insert after each heading -- I set that to zero.

> the fact that headings look like bullets to me make it harder to follow.

If you start using Org, it won't look like that. In fact, I use hyphens for list items in Markdown too as they work there too, so there is not too much context switching as I switch between Org and Markdown. I went through a lot of that as I was developing the ox-hugo package :)

Also in Org, lines starting with "# " are comments, which intuitively are comments in many languages. Markdown doesn't have comment syntax! I need to do stuff like below to fake a comment in Markdown:

    [//]: # "comment"

So the "headings look like bullets issue" will wear off once you start using Org, and then you wish Markdown also did the same :)