Re: mandoc -T html default style
Hi Ted, Ted Unangst wrote on Fri, Dec 21, 2018 at 02:53:19PM -0500: > Ingo Schwarze wrote: >> 2. When calling "mandoc -T html" without specifying "-O style=", >> fall back to "-O style=/var/www/htdocs/mandoc.css" by default. >> That might be sensible because it is adequate for local >> viewing of the file, which is likely intended with files >> generated in such a manual way. > I think this is probably not true. I would guess people are running > mandoc -T html to generate static files for a web server. Maybe. But if that is true, then inlining the full set of CSS rules is not a sensible default at all. If you install mandoc HTML files on a web server, you almost always want to use an external style sheet. I'm not saying that an inline style sheet is a poor choice in each and every case, but the cases where that might make sense are very rare and unusual. And something that is very rarely useful certainly must not be the default. Actually, if your guess what people are doing with files manually generated with mandoc -T html is true, then inlining the full set of CSS rules by default clearly makes matters worse than they are now. For that purpose, you really *have* to specify -O style=. If you do that, then the proposal to inline the full set of CSS rules by default provides no benefit. If you forget it, then with the status quo, it is obvious for you that you did something wrong because the pages look bad. It is even obvious what the problem is, simply by a casual look at the pages: lack of a style sheet. So it's easy for the user to notice, diagnose, and fix their error. If we inline the full set of CSS rules by default, we merely hide that typical user error. People may never even notice they did something stupid. If we think people predominantly use mandoc -T html to generate files to serve from static webservers, then i think we could make -O style=/mandoc.css the default, but *without* installing the file /var/www/htdocs/mandoc.css file by default. On a webserver serving static manual pages, having the style sheet in the document root is a sensible default (certainly not the only possibility, but one simple option that makes sense). So it will work out of the box for some, including man.openbsd.org, and those who want to put the stylesheet elsewhere can easily give a different -O style=. > I would suggest using a relative URL here, just "mandoc.css", I don't consider a relative URI a sensible default at all, assuming that people want to copy the files to a web server. Copying the style sheet to each and every directory containing manual pages doesn't seem sane at all, and besides, i would rarely want to mix HTML and CSS files in the same directory on a web server. > so the files can be copied around and viewed by people not > running OpenBSD. For offline viewing, a relative URI makes even less sense. The style sheet will almost never be in the same directory as your HTML files, unless you constantly copy it around. > But see below. > > Local OpenBSD users are probably just using the text tty output of man. > >> 1. Install /var/www/htdocs/mandoc.css by default. > I think this is a bad idea. Right, that idea was unanimously shot down. >> 2. Make "-O style=/var/www/htdocs/mandoc.css" the default in mandoc(1). > Maybe, maybe not, but as above, I'd argue for simply "mandoc.css". > However, I don't think we really need to make changes here. >> 3. Inline your version if the user says "-O style=''". > I would say just inline this by default. Leave the behavior of -O alone. I dislike that direction. It makes a fringe case the default and hides typical user errors. Here is another, hopefully better proposal. What about making -O style= *compulsory* unless "option style" is defined in man.conf(5)? Just error out when no style sheet is configured? That can be combined with inlining the full set of rules when -O style=inline is explicitly specified. Yours, Ingo
Re: mandoc -T html default style
Ingo Schwarze wrote: > 2. When calling "mandoc -T html" without specifying "-O style=", > fall back to "-O style=/var/www/htdocs/mandoc.css" by default. > That might be sensible because it is adequate for local > viewing of the file, which is likely intended with files > generated in such a manual way. I think this is probably not true. I would guess people are running mandoc -T html to generate static files for a web server. I would suggest using a relative URL here, just "mandoc.css", so the files can be copied around and viewed by people not running OpenBSD. But see below. Local OpenBSD users are probably just using the text tty output of man. > 1. Install /var/www/htdocs/mandoc.css by default. I think this is a bad idea. > 2. Make "-O style=/var/www/htdocs/mandoc.css" the default in mandoc(1). Maybe, maybe not, but as above, I'd argue for simply "mandoc.css". However, I don't think we really need to make changes here. > 3. Inline your version if the user says "-O style=''". I would say just inline this by default. Leave the behavior of -O alone. So: 1. Reduce the full style to a minimal version. Embed that. 2. Done. :) If you agree it won't be too much burden moving forward, I can make a diff shortly.
Re: undocumented nfs mount option "intr"
Otto Moerbeek wrote: > On Thu, Dec 20, 2018 at 09:31:45AM +0100, Landry Breuil wrote: > > > On Thu, Dec 20, 2018 at 09:26:33AM +0100, Solene Rapenne wrote: > > > Hi > > > > > > fstab(5) has an example for a nfs mountpoint using the "intr" option. > > > > > > That option isn't documented in mount(8) or mount_nfs(8) and in fact, > > > I've not > > > been able to find it anywhere. What is it doing? > > > > I think it's the fstab shortcut for -i option in mount_nfs(8). > > > > Looking at mntopt mopts[] in mount_nfs.c there are way more nfs specifc > options that are only documented as getopt flags and not as -o flags. > > -Otto would it be accepted to add the "named options" in mount_nfs(8), something like this diff? this is a quick draft Index: mount_nfs.8 === RCS file: /data/cvs/src/sbin/mount_nfs/mount_nfs.8,v retrieving revision 1.39 diff -u -p -r1.39 mount_nfs.8 --- mount_nfs.8 6 Jun 2009 20:58:50 - 1.39 +++ mount_nfs.8 21 Dec 2018 17:24:53 - @@ -163,6 +163,9 @@ Cache file attributes for at least .Ar num seconds. The default is 5 seconds. +.It Cm intr +This option is equivalent as using the flag +.Fl i . .It Cm port Ns = Ns Ar portnumber Use the specified port number for NFS requests. The default is to query the portmapper for the NFS port.
Re: break out separate wsmouse devices for ps2 types
For historical reference, Ulf has pointed out that I misunderstood what was going on here, and this diff is incorrect. There is a much more elegant way of handling this with xorg.conf that he pointed out using separate InputClasses with MatchIsTouchPad and MatchIsPointer options. Thanks Ulf, and thanks jcs@ for getting me started.
Re: Patch for install64.octeon : EdgeRouter 6 info
On Thu, Dec 20, 2018 at 07:39:44PM -0500, Chris McGee wrote: > That looks much better to me, though it does get machine-specific > > I feel like it would be more clear if the examples uniformly used your > new variable > convention, as some do and some do not. This allows us to eliminate one > example > too. (I assume the ER Lite does OK if you specify numcores=1 ? ) > > I left in the ER Lite machine-specific example about resetting the USB > controller. > I only booted my new ER6 from USB a few times before switching to MMC, > but it did not seem to have any issues detecting the USB controller or > devices. > (It WAS picky about what USB sticks it would work correctly with.) > > This is a diff from -current's /usr/src/distrib/notes/octeon/install > > me@box> diff -u install install.ori Please use cvs to generate diffs, so that the output would be applicable to the source code tree in the version control system. I have committed an adapted version of the patch.
Re: mandoc -T html default style
Hi Ingo, On Thu, December 20, 2018 11:53 pm, Ingo Schwarze wrote: > Hi Ted, hi Raphael, > > Ted Unangst wrote on Thu, Dec 20, 2018 at 11:36:06AM -0500: >> Raphael Graf wrote: > >>> The diff inserts some space above the footer. >>> This improves readability and makes it similar to the other output formats. >>> >>> Here is an example found in the wild, demonstrating the problem: >>> https://webassembly.github.io/wabt/doc/wasm-objdump.1.html > > How did that page get generated? By some Github automatic or > half-automatic infrastructure, and if so, how exactly? Or did the > maintainers of "webassembly" simply generate that file by hand? > Also, is that URI linked to from anywhere? It tried clicking around > the "webassembly" website, but failed to find any link to the URI > you cite. I guess the html-pages where generated and copied to the server by hand. It is the result of this pull request: https://github.com/WebAssembly/wabt/pull/979 There are links to these pages here: https://github.com/WebAssembly/wabt > >> So I think one answer to this problem is "use the provided mandoc.css". > > Absolutely. > > Or if it doesn't meet your needs exactly, edit it, then use your > edited version. > > Or if it doesn't meet your needs at all, write your own, using > mandoc.css as documenation of the available classes. > >> However, that's not the default. >> But perhaps it, or a variant of it, should be. > > I certainly love sensible defaults and hate the lack of them, > but in the past, i considered sensible defaults impossible > for "-O style=" because it is kind of hard to guess the file > system layout on the user's system, so we don't know which > absolute path to use in the line > . > Personally, I think having a minimal default inline stylesheet is not that bad. I like the fact that 'mandoc -T html' just works and produces a usable single file by default. (If there is inline css, it should be as minimal as possible because it should not change in the future. Old manpages would need to be regenerated otherwise.) > Let's try again. > What do you think about the following plan: > > 1. Let's install /var/www/htdocs/mandoc.css by default. > > 2. When calling "mandoc -T html" without specifying "-O style=", > fall back to "-O style=/var/www/htdocs/mandoc.css" by default. > That might be sensible because it is adequate for local > viewing of the file, which is likely intended with files > generated in such a manual way. > If the user then goes ahead and copies these files onto a > webserver, they of course cannot work because the document root > must be stripped from the "-O style=" argument in that case. > Also, if the user copies these files onto a non-OpenBSD system, > they stop working there, too. > > 3. To build HTML without any whatsoever, > require "-O style=" to be explicitly specified with an empty path. > > 4. Document all that in the mandoc(1) manual page below "HTML Output". > > 5. In man.cgi(8), we already use the equivalent > of "-O style=/mandoc.css" by default, unless CSS_DIR is > configured in cgi.h. That won't change. > >> I guess one objection to always using mandoc.css is that it's >> another file that may get lost. > > That's not really a counter-argument because nothing becomes worse. > Currently, by default, you never have a good stylesheet, and if you > configure one, it can already get lost, maybe even more easily > because it is not installed by default. With the above plan, you > get a working stylesheet by default for some simple cases, and you > can still build HTML files with a different one or even without any > if you want to. > > By the way, not that man.conf(5) already supports the > > output style /path/to/my.css > > directive. > >> And perhaps it's a touch too large to inline? > > Not a very convincing counter-argument either. If you use an > external stylesheet, which is almost always by far the most sensible > thing to do, nothing gets inlined in the first place. With the > above plan, in the unusual case that the user explicitly request > that no external stylesheet be used, inlining the whole thing is > still better than inlining something stunted, like we do now, i > think. Look at arbitrary websites nowdays: almost all serve > ridiculous amounts of boilerplate styling stuff. The size of > mandoc.css is really not a problem by comparision, and much less > for a corner case that isn't recommended anyway. > >> But we can trim it down some to where I think it can be reasonably inlined in >> every html and I don't think there will be many complaints about bloat. >> >> This is only a start. I noticed there's a lot of redundant definitions, and >> by >> inverting the selector property grouping we can trim many lines off the file. >> I don't think this impedes readability of maintenance. On the contrary, >> (personally) I find it easier to see all the italic tags in one place versus >> scanning a list of mostly
Re: Patch for install64.octeon : EdgeRouter 6 info
Den fre 21 dec. 2018 kl 01:40 skrev Chris McGee : > > I feel like it would be more clear if the examples uniformly used your > new variable > convention, as some do and some do not. This allows us to eliminate one > example > too. (I assume the ER Lite does OK if you specify numcores=1 ? ) "does ok" == runs only on one core, but runs. -- May the most significant bit of your life be positive.
