User talk:Lahwaacz

From ArchWiki

bot checking links after move

Hi, re Talk:Touchpad Synaptics#adding libinput alternative. Touchpad Synaptics has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of Touchpad Synaptics and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --Indigo (talk) 07:36, 26 September 2015 (UTC)Reply

Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a UUID page, which was later generalized and renamed to Persistent block device naming and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace [[pacman|Install]] with [[Install]] etc. -- Lahwaacz (talk) 08:01, 26 September 2015 (UTC)Reply
Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [1]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --Indigo (talk) 10:02, 26 September 2015 (UTC)Reply

Automatic template correction

Per Help:Template#Style, templates should be used with the capitalization shown in the examples in their pages, so {{AUR|... is correct, while {{aur|... is not.

However, there are pages that don't respect that rule (e.g. Android_Debug_Bridge until recently).

I beleive this correction should be easy to implement using a bot. What do you think?

—This unsigned comment is by Relrel (talk) 07:24, 25 August 2020‎. Please sign your posts with ~~~~!

Yes, this should be easy, but the bot should not make a huge amount of simple style-only changes - they should be combined with corrections for more complex rules. Anyway, there is an idea to create a style linter for the ArchWiki rules. Would you like to help? ;-) – Lahwaacz (talk) 09:21, 25 August 2020 (UTC)Reply

Readability in Wiki

I noticed that you and the other admins and moderators often want sentences to continue endlessly, without line breaks. For example in the introduction of Wayland.

I think it would be better to have more seperated sentences, so it is easier to read and "important" information is easier visible for people. I don't know who is responsible, but maybe some options in MediaWiki (or whatever this wiki software is) could be changed as well, to make make line breaks etc. easier and reduce the height-space (if you know what I mean) between sentences, so it looks better, even though line breaks are used.

G3ro (talk) 14:38, 15 October 2020 (UTC) G3roReply

I don't know exactly what you mean. Is it about the readability of the rendered HTML or the "source code" of the page? -- Lahwaacz (talk) 19:15, 15 October 2020 (UTC)Reply
Well I guess it can be about both. But mainly it is about what people see on the page.
There are three seperate topics I mentioned:
1. Use line breaks: I would like to use more line breaks, because if you have long sentences that are written after each other without line breaks, it gets "harder" to recognize when the next sentence starts.
While I agree to what you said somewhere, that sentences that belong directly together, should be written in one "paragraph", it would be useful for sentences that cover (slightly) different "topics" to be visibly parted.
2. Adjust margin options: I notice that when line breaks are used, there is a vertical space added between two sentences. Just like in this post. If you would use line breaks more often, this is a little too much spacing in my oppinion.
3. Potential options to make line breaks easier: It would be very convenient if a line break in the source code would lead to a line break in displayed text as well, instead of needing to add an empty line.
G3ro (talk) 20:33, 15 October 2020 (UTC) G3roReply
OK, now I understand. I agree that splitting different topics usually improves legibility, but they should be split into separate paragraphs and not just by line breaks (e.g. using the <br> tags). Paragraphs are semantic units whereas line breaks inside a paragraph are usually typographic errors.
Also note that such splitting alone may not be enough to improve the text flow. For example, if we consider the intro for Wayland, the second sentence about XWayland would not constitute a good paragraph - it is just a plain statement and the new topic is not nicely introduced. Ideally, you'd split the topic and make some wording changes for the second paragraph.
As for the margin options, that is the difference between paragraph splitting and non-semantic line breaks. In my opinion, the styling is correct in this respect, as paragraphs should be discernible. You mentioned that you like line breaks to easily recognize where a sentence ends - but reading should be based on whole paragraphs, not sentences. There should be no reason to skip anything in the middle of a paragraph, otherwise it should be probably split into multiple paragraphs or otherwise rephrased.
If you find it hard to follow a long sentence horizontally on a wide screen, we might consider enforcing some maximum width for the whole content. I think the readability would be better, since there would be more top-to-bottom eye movement at the cost of left-to-right-and-back.
-- Lahwaacz (talk) 20:59, 15 October 2020 (UTC)Reply

Root on ZFS draft

Hi, I submitted a Root on ZFS draft to official doc repo.

In the draft, the following directories are separated from root filesystem:

home,root,srv,usr/local,var/log,var/spool,var/tmp

Is this appropriate for Arch Linux? Or do you have any suggestion on the draft? Any comment is appreciated. M0p (talk) 01:28, 23 January 2021 (UTC)Reply

Network configuration edit

Hello

You reversed my edit in the network configuration pages (https://wiki.archlinux.org/index.php?title=Network_configuration/Wireless&diff=next&oldid=788365) because you stated it was out of scope and tlsv1.0 is insecure

I disagree on the first part, many people I know, I first have struggled to configure eduroam on archlinux and this place seems the best fitted

On the second part, I agree tlsv1.0 is outdated and insecure, sadly it's the one used in some schools Ultraxime (talk) 17:11, 4 October 2023 (UTC)Reply

VCS revert

https://wiki.archlinux.org/index.php?title=VCS_package_guidelines&diff=0&oldid=802958

While the VCS page isn't about AUR, I feel that the short Note about not bumping up pkgver needlessly is still a welcome addition to it, and additionally linking to the AUR policy is a fine crosslink.

C0rn3j (talk) 15:42, 11 March 2024 (UTC) C0rn3j (talk) 15:42, 11 March 2024 (UTC)Reply

You can already link to the note in Arch User Repository#Flagging packages out-of-date. — Lahwaacz (talk) 16:58, 11 March 2024 (UTC)Reply
That's exactly the note I linked, VCS package guidelines for AUR deserve such a footnote on this page.
Just today I went to link the VCS page to a friend confused about -git packages, only to again find out that's exactly the page that is missing any kind of mention about it.
Please reconsider. C0rn3j (talk) 11:58, 22 May 2024 (UTC)Reply
You should just direct people to Arch User Repository#Flagging packages out-of-date. The VCS package guidelines page is not about the AUR out of date button and the upgrade process. — Lahwaacz (talk) 10:51, 22 June 2024 (UTC)Reply

About the "Intel washed colors" revert

Sorry if I'm doing this wrong, it's my first time contributing and trying to talk with someone on the archwiki.

> - not a driver problem, add this to the page of your laptop

I didn't specify properly, but this is a problem that happens on other setups too, some people at work have the same problem on their Thinkpads and other Dell models, basically the only requirement for this problem to happen is: have an Intel iGPU (I never seem a case of it happening on offboard GPU) and a monitor that is not recognized as full color by default.

I also have AMD and Nvidia GPUs, and this still only happens on my Intel iGPU

I don't think this is something that only fits my model of laptop, and I have not found anothe page that is related to this problem. Shinsei (talk) 16:26, 11 August 2024 (UTC)Reply

Ah, ok. I've added the section back: [2]Lahwaacz (talk) 11:42, 17 August 2024 (UTC)Reply

Install Arch Linux on a removable medium

Its not an edge case, there is still plenty of BIOS machines. Real edge case is a person who installs arch on USB stick :) it is not a general advice, please read it again carefully.

https://wiki.archlinux.org/index.php?title=Install_Arch_Linux_on_a_removable_medium&oldid=815197 Omeringen (talk) 16:14, 24 August 2024 (UTC)Reply

Workaround to use suspend-then-hibernate with GNOME on lid close

You reverted my message stating 'systemctl suspend-then-hibernate works on GNOME'. (It's the last contribution on my user profile)

Of course you can run 'systemctl suspend-then-hibernate' but as I described, there is no way to trigger a suspend-then-hibernate from GNOME. I found a neat way to trigger this anyway and that's what I describe. I thought this trick would be of interest to other people so I thought about contributing and sharing it on the Arch Wiki. Do you disagree that this would be useful information. If so, why? Or might this be of interest on some other page? Starquake (talk) 13:48, 21 October 2024 (UTC)Reply

What I meant is that you can run the systemctl suspend-then-hibernate command even on GNOME. If you are missing a graphical button somewhere, it can't be considered part of the "support in GNOME" and it is not really relevant on the Power management page. — Lahwaacz (talk) 12:41, 27 October 2024 (UTC)Reply
Okay, thanks, I'll see if this would be useful to mention on some other page. Starquake (talk) 17:36, 27 October 2024 (UTC)Reply