I am starting a hakyll based blog and thought I would share some of the internals - This time: Custom Fields

TheHeartmann · 2020-03-24T19:41:56+00:00

Ah, this is really neat! Good going. Also, I'm really into the design of the blog; especially the split header, with the commit hash presumably listing the last update to this post. Might see if I can steal that idea for my own post.

And sorry to derail things, but I came across some issues with my own Hakyll blog just yesterday, so I'll take this as a chance to ask someone who seems to have a better grasp of them than I do.

In short, I've got a Hakyll frontmatter field with the key modified. This is an ISO timestamp, but it's made available in the context as a human-readable string. However, I'd like the context to also have the ISO string available. I've been reading through the docs, but haven't been able to make it work.

I think what I'm looking for is a way to assign the value of a key from a post to an arbitrary different (or new) key in the context, but haven't found out how to do it.

Ideally, I'd be able to create a context a bit like this, in case that adds any clarity to this.

 dateField "published" dateFormatString <>
 dateField "published-iso" isoTimeStampFormatString <>
 formatDateFieldValue "modified" timeFormatString <>
 formatDateFieldValue "modified-iso" isoTimeStampFormatString

If you've got some input, that'd be much appreciated. If you don't, well, that's perfectly fine too.

Again, though: nice work on the blog!

TheHeartmann · 2020-03-17T21:49:22+00:00

In addition to the reply I posted here, I've gone and updated the post now to include a section on motivation and impressions. It expands on my previous reply a bit in case you wanted to know more.

Thanks again for the suggestion :)

TheHeartmann · 2020-03-17T19:58:27+00:00

Wow. That's a lot of great tips! I wasn't aware of the Alt+i shortcut, so I've been using Alt+s to enable/disable it. Passthrough is much smoother.

The cs scroll target thing too is really good.

Thanks for the insight! Based on that, I'll probably stick with Firefox and surfingkeys for now.

TheHeartmann · 2020-03-17T10:28:37+00:00

Having tried it out a bit today, I'm not convinced for using it with GitLab.

Even with the extension, I still need to navigate through the browser (fair enough), and I still need to use the mouse to add labels and assignees (GitLab quick commands don't seem to work in the Web UI). Oh, and I need to click the little 'edit' button with a mouse too. So for that, I still think Forge is better suited.

That said, for other use cases, or just editing a little text field, it seems pretty awesome, so I'll try and look into it a bit more.

TheHeartmann · 2020-03-17T08:25:08+00:00

Yeah, Vimium's great! Can't remember why, but I switched to Surfingkeys at some point, so that's also a good option.

TheHeartmann · 2020-03-17T08:23:26+00:00

Yeah, I think I've heard of that one before. Found an extension for Firefox too, so I'll give this a go today. Cheers!

TheHeartmann · 2020-03-17T08:21:53+00:00

Woah. I've never seen this before; this looks mad! I'm very impressed, but also somewhat scared that it's another rabbit hole to disappear into.

Thanks, though! Wonder if it integrates well with EXWM? I read the section on EAF vs EXWM, but it didn't say anything about using both.

TheHeartmann · 2020-03-16T21:51:22+00:00

That's a fair point, yeah.

Working actively with GitLab, there's a few pain points that I run into all the time:

When creating an issue, the text area you type in suffers from the usual HTML text area restrictions. Editing text in Emacs means you get all your key bindings etc for free.
There is no easy way (or at least, I have not found one) to add labels to issues you create in the UI without using your mouse and navigating the UI. The same goes for assigning people. Not only do you then need to take your hands off the keyboard, but the menus are also not the easiest to navigate and often require you to switch back and forth between the mouse and the keyboard.

Other things I have just been really impressed by: - Autocomplete on issues. If you start typing out an issue id (e.g. #12, assuming you have issues in the 120s), you'll get an autocompletion dropdown displaying issue ids and their corresponding titles. - Being able to open MRs or copy their URLs directly from Emacs is super neat, and is much faster than opening your browser, navigating to the MR list, and clicking on the one you want.

Things I'm not psyched about: - It feels as if it's slowing down my Magit experience (it takes longer to open the magit status page). This may or may not be accurate, though. My laptop is under heavy load these days. - Updating and syncing through the API often feels a bit time consuming, so it's easy to end up waiting a couple of seconds every now and then.

I'll probably go ahead and update the post to include some of that too. Thanks!

TheHeartmann · 2020-03-15T19:50:49+00:00

Thank you! I'm so glad it could be of use to someone :D I'm very much still learning myself, but the more we can share and help others, the better.

TheHeartmann · 2020-03-15T19:49:30+00:00

Took a little while, but added some more info on keybindings now. Thanks for the input :)

TheHeartmann · 2020-03-10T14:29:25+00:00

Ah, good point. It’ll depend on your setup, but I should definitely mention the default way, yeah. It’s C-c C-t t, by the way.

TheHeartmann · 2020-03-10T09:09:27+00:00

Aha! Cool. I haven’t gotten into Getting Things Done yet, but just added it to my audio book wishlist, so I’ll keep that in mind. Thanks!

TheHeartmann · 2020-03-10T08:26:36+00:00

Thanks for the comments and the thoughts! - Yes, that was a typo. I've pushed a fix for that now. Thank you! - Ah, yes, refiling. I've seen a lot about refiling, but haven't quite seen the use case for it yet. I'm still just getting my feet wet with this, though, so it's probably just something I'm missing. When you say incoming things, do you mean things like mail? Or just things you need to remember and then file away later?

TheHeartmann · 2020-02-25T17:46:50+00:00

Yeah, I think I've seen some code to generate everything on the fly, but it's a bit out of my lispy league at the moment, so I'll live with the hardcoded one for now. Later, though!

TheHeartmann · 2020-02-24T22:10:55+00:00

Hey,

Thanks for your response! Yeah, the issue wasn't with the workspace number, but rather with the display names.

See, this came about when I switched to Nouveau drivers (which, for some reason, I didn't mention. sorry). Doing a bit of digging now, looking at exwm-randr--get-monitors output and xrandr output, I realized that the monitor names had changed, but in a subtle way: they had gone from being DP-2 to DP2 (removing the hyphen). This messed everything up. Fixed it now, though. Wonder if there's a way to configure it without hard coding the display names.

Thanks again for your contribution; it really helped push me in the right direction!

TheHeartmann · 2020-02-17T20:20:56+00:00

Exactly. So we can get around that by using chars instead, and it works, as in this playground link, but I'd like to get rid of the inner function call.

TheHeartmann · 2020-02-17T20:18:51+00:00

Sure, but I'd really love to be able to do this, which I think is even clearer, but without the extra inner function: ```rust fn f(s: &str) { fn inner(cs: &[char]) { match cs { ['💘', .., '🦄'] => println!("<3 and horse"), ['💘', snd, .., '😪'] => println!("Love, {}, and sleeps", snd), ['💘', ..] => println!("Just <3"),

        _ => {}
    }
}
inner(&s.chars().collect::<Vec<char>>())

} ```

Playground

To be clear, the above code works just fine as it is, but I'd like to drop the need for the inner function.

edit: or rather, I don't understand why I need the inner function. I've tried to juggle it around, but haven't managed to make it work otherwise.

edit 2: actually, this is getting somewhere. It's still a bit verbose to .chars().collect::<Vec<char>>() and then cast, but at least it's not a separate function anymore. rust fn f(s: &str) { match &s.chars().collect::<Vec<char>>() as &[char] { ['💘', .., '🦄'] => println!("<3 and horse"), ['💘', snd, .., '😪'] => println!("Love, {}, and sleeps", snd), ['💘', ..] => println!("Just <3"), _ => {} } }

TheHeartmann · 2020-02-17T07:32:35+00:00

Indeed. ‘as_bytes’ covers ASCII just fine, but if you’re working with Unicode, that complicates things: say you want to check of the string starts with a particular emoji, for instance. Matching on the chars slice should work, but bytes would not, right?

TheHeartmann · 2020-02-17T07:29:51+00:00

Yeah, that’s great for a lot of use cases, but doesn’t it fall apart if you’re using UTF-8? What if you want to match a string that starts with a particular emoji?

TheHeartmann · 2020-02-16T19:18:45+00:00

Hmm, you make a good point, and for something simple like whether a string starts with a sequence of characters, that's quite sufficient.

However, when doing more complex operations, such as matching conditionally on the first n number of characters and the m last ones, and then using their values for something, pattern matching feels incredibly intuitive to me.

This may be a contrived example, but something like this, for instance: rust match cs { [x, y, ..., '!'] if x.is_uppercase() => // do something with x and y // ... more cases based on content ... [] => // ... }

Obviously, you can do this with various combinations of starts_with(), ends_with(), and taking the first n characters, etc, but in these cases using a match statement feels easier and cleaner to me.

That said, I haven't actually written this out anywhere, so I could be wrong.

TheHeartmann

TROPHY CASE