Hacker Newsnew | past | comments | ask | show | jobs | submit | z2h-a6n's commentslogin

I've used both, though I'm not sure I can compare them directly, since it has been a year or more since I switched from Hacker's Keyboard.

Unexpected Keyboard works well for me when using Termux, possibly even better than Hacker's Keyboard, since I find it easier to swipe on a key to get to uncommonly-used symbols rather than switching to a different keyboard layer. Every now and then I accidentally swipe a key when I meant to press it, and end up entering a accented character when I didn't mean to, but this is fairly rare. I don't use Termux very often, but for occasional vim or terminal usage it's totally sufficient.

One cool feature of Unexpected Keyboard (which may be available elsewhere, I haven't looked at many others) is that you can swipe left and right on the space bar to quickly and accurately scroll left and right in a text field. I find this about as fast as tapping at a position in a text field, but much more accurate.


> One cool feature of Unexpected Keyboard (which may be available elsewhere, I haven't looked at many others) is that you can swipe left and right on the space bar to quickly and accurately scroll left and right in a text field.

Nice! That's a feature of Google's GBoard, which ships as the default on Pixels but is available to most Android phones. I use it extremely often (including twice while writing this comment) and not having it is one of the big reasons I found Hacker Keyboard frustrating. Hearing that Unexpected Keyboard has it is pushing me over the edge to give it a trial run.


Gboard's implementation is super annoying for me because it keeps trying to skip over word boundaries, and it's quite difficult to move just one or two characters over, because it waits for you to swipe far enough before activating any movement. Just awful.


> Gboard's implementation is super annoying for me because it keeps trying to skip over word boundaries, and it's quite difficult to move just one or two characters over, because it waits for you to swipe far enough before activating any movement. Just awful.

This is interesting—Gboard also by default uses a long-press on the space bar to change keyboards, so I often find myself triggering that while meaning to scroll (or, more often, meaning to long press 'n' for '!'), but, as long as I'm quick enough, I've never observed it to be hesitant about moving one or two characters.


Does GBoard allow you to select text by pressing shift and then swiping on space?


I just found out I can do it on iphone thanks to your comment. Wow.


One hugely underated offering of unexpected keyboard is the ease with which you can define entierly new keyboards. Want a keyboard for futhark runes? They're unicode so go for it, you totally can. Like thorn as a concept and a character, and want to use it with ease? þen add it for easy use. This keyboard is truly the hackers keyboard. I spent a month using termux exclusively, writing cli apps for things as i needed them and without unexpected keyboard that would have been a really painful experience, rather than mildly inconveniant at times.


Apologies for pedantry: in ðat case you should have used Þ U+00DE LATIN CAPITAL LETTER THORN, as it begins a sentence.


This is what I come to HN for


Fantastic addition, no appologies neccesary.


> is that you can swipe left and right on the space bar to quickly and accurately scroll left and right in a text field. I find this about as fast as tapping at a position in a text field, but much more accurate

I recently learned about a hidden iphone feature. If you hold the spacebar for about halve a second you can move freely the cursor around any text field.


If you want to be specific, specify the solid angle [0] captured, in your prefered units, e.g 4π steradians = 41253 square degrees = 1 spat.

[0] https://en.wikipedia.org/wiki/Solid_angle


I'm not sure if eddyg had a different idea, but I think the following sums it up:

  - base16 is a specification of how different UI elements map to colors [1], and also some tooling, configuration files, etc. to automate setting this up for many different applications.
  - For a user to be able to use base16 with a tool, either:
    - Allow the user to set their preferred colors for UI elements at a semantic level, preferrably in a config file, and even more preferrably in a separate file that can be included into the main config file so that it's easier to automate (i.e. I have a separate `colors.sh` that is loaded in my `.zshrc`).
    - Let the user set their shell colors however they want (presumably using [2]), and use the ANSI shell colors (and a few more) according to the base16 style guide [1]. Some translation between shell colors and base16 colors will be necessary, e.g. base16 says that a language keyword should use the color base0E, which in [2] corresponds to ANSI shell color 13.
My impression is that the base16 specification is not sufficiently general for most tools to implement it in a totally unbambiguous way, but if users can set their own colorschemes with a config file, it's not hard for a user to come up with a base16-approximating colorscheme template file, from which other users can generate a config file that sets a specific base16 colorscheme.

[1]: https://github.com/chriskempson/base16/blob/main/styling.md [2]: https://github.com/chriskempson/base16-shell


> the texture of the rice will come out quite wrong.

Out of curiosity, in what sense can the texture be wrong? I never wash my rice, and I like the texture.


Washing rice is one of those hygienic practices that evolved into a social more and was incorporated into regional cuisine thereafter. If you're living in a developed country with effective food safety regulations, you don't need to wash your rice.

Which doesn't mean that it's a bad idea to wash your rice. But it's certainly not inherently wrong to not wash rice. For certain cuisines you're actually supposed to not wash the rice, like when making risotto or paella.


So rice. Out of the plant, rice is not that white grain we're used to see. It has a protective layer (called bran). It has all kind of nice nutrient in it, but also contains quite a lot of oil and can go rancid. So for conservation purpose, it's usually removed. The way it's removed is by grinding it until we get to that white layer we all know.

Now this white layer is mostly starch. And by grinding the grain up to this white layer, you necessarily make a lot of microscopic starch powder (I'm simplifying).

When you rinse the rice, you remove this microscopic powder. So when cooking, it cannot gelatinize and provide that creamy (... or goopy, depending on your point of view) texture.

Note that this preference depends on the cuisine, cultivar and even recipe. As other mentioned, risotto is supposed to be creamy, banh chung is held together by magic, pilaf have distinct grains, etc...


You explained that very clearly, and I am grateful for that.


There's nothing wrong with liking it that way, it's just more porridge-like because of the starch if you don't wash it and some people prefer individual rice grains.


Individual rice grains remind me of ant larvae.


Unwashed rice is normally gummier or more starchy


Try it for once. You'll notice the difference


Rice contains a lot of arsenic. Washing it can remove some of it. This article also recommends pouring off some water during cooking as well.

https://health.osu.edu/wellness/exercise-and-nutrition/how-t...


This doesn't answer the texture question.


Your somewhat inflammatory "rice contains a lot of arsenic" isn't supported by your source, which has the much more equivocal "rice may have arsenic in it — potentially high levels".


I doubt they meant it as being inflammatory. It's just a fact, if you don't read it as being perfectly literal. I parboil my rice and pour off the water before cooking it to try and avoid arsenic exposure (which is more or less a washing procedure). This also gives it a nice fluffy texture, but if asked why I do this, I would say something similar to GP.


> It's just a fact, if you don't read it as being perfectly literal

What other kind of fact is there?


"Rice has a lot of arsenic" reads the same as "rice may have arsenic in it — potentially high levels" if you don't take it as literally applying to all rice in all circumstances.


Are you perhaps referring to the latest release (which was 1.4 years ago) rather than the latest commit on main (which was 41 days ago)?


Not to nitpick (I only stumbled upon this recently myself), but the mechanism driving a Crookes radiometer (which I presume is the type you're talking about) is not photon pressure, but interactions with the low pressure gas in the bulb [1].

[1]: https://en.wikipedia.org/wiki/Crookes_radiometer#Explanation...


Yes(!): the explanation on the little paper that came with it explained such.


I disagree, as long as we're talking in ratios instead of absolute amounts. The difference between "a pinch of baking powder" vs "5 grams of baking powder" is about a factor of 20. I think the main differences between baking and other cooking are that: 1) There are often very large ratios of certain ingredients in baking which -- except for spices -- is not generally the case in other cooking; 2) You can often taste the food in an intermediate stage when cooking, and adjust the ratios -- e.g. for spices -- which is not generally as useful when baking.

Of course using a scale is a good way to keep the ratios from getting too out of wack, and I usually do it too when baking and almost never when cooking.


I bought a scale a number of years back and, yes, I pretty much universally use it for baking--it's just easier as well as being more repeatable/accurate--and rarely for other types of cooking.


scales are wonderful for measuring oil/liquid though. Putting a bowl on a scale and pouring 54 grams of olive oil is so much easier and accurate then measuring out 3 table spoons of oil


I find those sorts of measurements are less likely to be given in recipes though. I do agree that weight is generally better than volume when it's given in a recipe.


How about this: two objects are touching when the interaction forces between the objects are of similar magnitude to the interatomic forces within the objects. Very generally speaking, this will happen when the distance between the objects is about the same as the distance between atoms within the objects.


Ok, so I conclude from this that touching is not an exact science.


To be somewhat pedantic: "touching" is a word. The extent to which it is or is not an "exact science" depends on what is meant by "touching", and by "exact science". The definition I gave of "touching" could be made arbitrarily more precise by specifying more precisely the interaction forces under consideration, and the level of precision to which one should compare their magnitudes. What you mean by "exact science" is something I cannot guess at with any useful level of precision. Whether or not any of this has any bearing on the original topic of discussion is another matter.


I mean, the actual interaction force that defines "touching" is open for debate. Touching is an abstract concept, removed from actual physics.


That was sort of my point. If we use a definition of "touching" that is relevant to the atomic scale, whatever that definition is, we can reasonably talk about what "touching" means at an atomic scale. If we use a colloquial definition of "touching" which is meaningful for macroscopic objects but not at the atomic scale, it doesn't make sense to talk about "touching" at the atomic scale.


disclaimer: I'm not an expert, but I've been watching some geology lectures focused on the pacific northwest [1] for fun recently.

This is on the Jaun de Fuca Ridge, on the other edge of the Juan de Fuca plate [2] from the Cascadia subduction zone, so it's related in the sense that it's the same tectonic plate, and the plate is very small (as far as I understand, it's a remnant of a plate that has been subducting under North America for a very long time). It is not (in my very-non-expert opinion) necessarily related in a direct sense to what is happening in the subduction zone.

[1]: e.g: https://www.youtube.com/playlist?list=PLcKUIuDhdLl92gfymRabw... [2]: https://en.wikipedia.org/wiki/Juan_de_Fuca_Plate


Wow, that playlist is absolute gold. These kinds of instructional, high-quality, long-form lecture series are IMO maybe the best thing on the internet. The kind of thing when I encounter it makes me take a step back and really appreciate the fundamental beauty and utility of the internet.

A few other examples:

  - https://www.youtube.com/playlist?list=PL9GwT4_YRZdBf9nIUHs0zjrnUVl-KBNSM
  - https://www.youtube.com/watch?v=ncd6q9uIEdw&list=PLND1JCRq8Vuh3f0P5qjrSdb5eC1ZfZwWJ
  - https://www.youtube.com/watch?v=ycJEoqmQvwg&list=PLbN57C5Zdl6j_qJA-pARJnKsmROzPnO9V
  - https://www.youtube.com/watch?v=Ps8jOj7diA0&list=PL9D558D49CA734A02
 
Sometimes I wish there was a frontend for YouTube that only has these kind of long-form lecture series, but I've never found one. I think part of the reason why is that essential "quality" is somewhat ineffable.


That is the common interpretation in the field, and in fact the phrases "strange metal" and "non-Fermi-liquid" are used somewhat interchangeably.

I'd point out that there is another interpretation of resistivity that is linear in temperature, namely that the basic physics of electron transport [1] is the same as a standard metal, where the scattering rate (proportional to resistivity) is proportional to temperature squared. The difference from normal metals is attributed to the linear increase in the carrier concentration (e.g. density of free electrons) with temperature. Since the carrier concentration (in the simple model) is inversely proportional to resistivity, this partially cancels the T^2 dependence of the scattering rate and produces T-linear resistivity. This is not (yet?) widely accepted in the literature, and I doubt it can explain all T-linear resistivity, but I think there's fairly strong evidence to believe it could explain some instances of T-linear resistivity, e.g. in the cuprates [2]. (n.b. I'm academically associated with some of the proponents of this idea, though I'm personally somewhat agnostic on the matter.)

[1]: https://en.wikipedia.org/wiki/Drude_model [2]: https://iopscience.iop.org/article/10.1088/1367-2630/ab4d0f


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: