Re: man to render pure text? (or a pipe in vi macros ?)
hello Ingo,
> Heck, piping to sort, or wc + undo are two of the most common used
> commands.
no need to pipe and undo: just write to a pipe
:%w !wc
> Under vi, !}fmt is also a favorite
> though vim does have better integrated commands...
AFAIK, ! work exactly the same between vim and vi. even !!
to recall the last filter works so
!!!^M
apply the last used filter on the current line. vim makes !
even more enjoyable because it combines with extra features
in a so convenient way. an example is gF:
let's say you're reading a mail in where the sender refers to
this function_with_a_very_long_name() you never read of
before ... and you want to see some code.
in vi you can
:cd ~/src/myproject
:!ctags -R
:tag function_with_a_very_long_name
the most borring part were to write the :tag line (or you
had to use the mouse).
in vim, you will edit the command line (:h q:) in a buffer
and use completion (:h i_CTRL-N)
q:tag fun^N
cool ... but now you want navigate through the calls of this
function? use gF (:h gF):
# means "carriage return" in the vim macro notation
# is for CTRL+x
:new # or n to split
q:r !grep -RFwn fun
now you have a new buffer with lines like
main.c:45:function_with_a_very_long_name("/etc/hostname",3);
put your cursor in on the filename, type gF (or if you want to
split) and here you are: in file main.c line 45.
the use and abuse of the quickfix (:make, :set aw, ...) boosted my
productivity too. piping and forking aside: i already mentionned the
text objects (:h text-objects) in another thread but once you have this,
you can't consider vi as a decent replacement of vim. no matter how
bloated vim is. it an editor with a better balance between simplicity
and functionality existed, i'll use it for sure.
marc
PS: i'll run a workshop on vim/vi during the next slcon (not announced
yet) so it will be a good opportunity to make this thread goes on.
Re: man to render pure text? (or a pipe in vi macros ?)
On Wed, Mar 04, 2020 at 03:42:47PM +0100, Marc Espie wrote: > On Mon, Mar 02, 2020 at 06:25:47PM +0100, Ingo Schwarze wrote: > > Yikes. I had no idea what either of these are doing and had to > > try them out. vi(1) contains so much bloat that is never really > > needed and doesn't belong in a text editor at all. > > No, all of this does belong in a text editor. > > I use vi/vim with escapes *all the time*. > > writing some text, having to do some computation, > > type 42+15, select it !bc, and that's it, instant computations. > > > seamless integration between shell and text editors is something that's > in both major editors on Unix (vi family and emacs family). > > If you're not using that, you are in the minority compared to power users. Heck, piping to sort, or wc + undo are two of the most common used commands. Under vi, !}fmt is also a favorite, though vim does have better integrated commands...
Re: man to render pure text? (or a pipe in vi macros ?)
On Mon, Mar 02, 2020 at 06:25:47PM +0100, Ingo Schwarze wrote: > Yikes. I had no idea what either of these are doing and had to > try them out. vi(1) contains so much bloat that is never really > needed and doesn't belong in a text editor at all. No, all of this does belong in a text editor. I use vi/vim with escapes *all the time*. writing some text, having to do some computation, type 42+15, select it !bc, and that's it, instant computations. seamless integration between shell and text editors is something that's in both major editors on Unix (vi family and emacs family). If you're not using that, you are in the minority compared to power users.
Re: man to render pure text? (or a pipe in vi macros ?)
hello Ingo, > > rare cases. so i finally think it's not worth ... col -b is an elegant > > solution. > Premature optimization is evil. this case isn't about optimizing, it's about slowing down 99.999% to add a case that already have an elegant and simple solution. but as i said: i don't feel skilled enough to be sure of anything. your call ;) cheers marc
Re: man to render pure text? (or a pipe in vi macros ?)
Hi Marc, Marc Chantreux wrote on Tue, Mar 03, 2020 at 10:05:41AM +0100: > Ingo Schwarze wrote: >> :map K yw:E /tmp/vi.keyword.$$p!!xargs man >> >> i get: >> >> Error detected while processing function >> line 30: >> E132: Function call depth is higher than 'maxfuncdepth' > it's a bug in the :E command, i reported it there: > > https://github.com/vim/vim/issues/5723 > > thank you for spotting it. Heh. I'm a blind squirrel, and look at the nut i just found... >> Also, the patch that would be required is very small and straightforward. > indeed. you made me like reading C code. >> So, what do people think? Should i test the patch below in more >> depth and commit it? Or do people consider this bloat? > i'm very naive about performance things but: as you add a condition > in a loop that is used while reading the input, it will be a little > bit slower. > which means penality for everyone to avoid using a very simple pipe on > rare cases. so i finally think it's not worth ... col -b is an elegant > solution. I ran "mandoc /usr/share/man/man1/ksh.1" 100 times, 10 times. Before the change: 0m07.65s real 0m05.68s user 0m01.52s system 0m07.62s real 0m05.92s user 0m01.47s system 0m07.64s real 0m05.97s user 0m01.49s system 0m07.62s real 0m05.90s user 0m01.42s system 0m07.68s real 0m06.13s user 0m01.51s system 0m07.65s real 0m06.01s user 0m01.46s system 0m07.66s real 0m05.89s user 0m01.50s system 0m07.60s real 0m05.89s user 0m01.54s system 0m07.73s real 0m06.00s user 0m01.38s system 0m07.68s real 0m05.70s user 0m01.47s system 7.653 +- 0.037 seconds for 100 times ksh(1) 76.53ms +- 0.37ms for formatting ksh(1) After the change: 0m07.68s real 0m06.22s user 0m01.34s system 0m07.62s real 0m06.02s user 0m01.42s system 0m07.68s real 0m05.87s user 0m01.46s system 0m07.66s real 0m06.01s user 0m01.41s system 0m07.59s real 0m06.00s user 0m01.41s system 0m07.62s real 0m06.09s user 0m01.20s system 0m07.63s real 0m05.95s user 0m01.44s system 0m07.67s real 0m05.83s user 0m01.48s system 0m07.59s real 0m06.11s user 0m01.46s system 0m07.71s real 0m05.86s user 0m01.45s system 7.645 +- 0.041 seconds for 100 times ksh(1) 76.45ms +- 0.41ms for formatting ksh(1) So the slowdown is -8 +- 55 microseconds for formatting ksh(1) which is consistent with "no change" with a precision of about 7 permille. It would no doubt be possible to measure this with more precision, but i think knowing that there is no measurable performance change on a one-percent level is good enough. Also, i'm not surprised that one more "if" per output character isn't relevant compared to all the other stuff that needs to be done in the parsers and formatters. I still do performance testing before changing overall algorithmic order, but mere "if"s are almost never relevant. I even mostly stopped worrying about malloc(3) inside loops; at least in mandoc, i have rarely seen relevant effects of slowdown. Premature optimization is evil. Yours, Ingo
Re: man to render pure text? (or a pipe in vi macros ?)
Le 02/03/2020 à 17:59, Marc Chantreux a écrit : i felt dumb reading this as i gave a try to the mandoc man. but i just double checked: man mandoc|col -b|grep -w col Hmmm, here I have it though: https://man.openbsd.org/mandoc In the “ASCII Output” paragraph. -- David
Re: man to render pure text? (or a pipe in vi macros ?)
hello Ingo, > :map K yw:E /tmp/vi.keyword.$$p!!xargs man > > i get: > > Error detected while processing function > line 30: > E132: Function call depth is higher than 'maxfuncdepth' > Press ENTER or type command to continue it's a bug in the :E command, i reported it there: https://github.com/vim/vim/issues/5723 thank you for spotting it. > Also, the patch that would be required is very small and straightforward. indeed. you made me like reading C code. > So, what do people think? Should i test the patch below in more > depth and commit it? Or do people consider this bloat? i'm very naive about performance things but: as you add a condition in a loop that is used while reading the input, it will be a little bit slower. which means penality for everyone to avoid using a very simple pipe on rare cases. so i finally think it's not worth ... col -b is an elegant solution. regards marc
Re: man to render pure text? (or a pipe in vi macros ?)
> I have no idea what the "much more" refers to. all the things i can do with vim are very useful while reading a man page. * a file is mentionned ? use gf to jump in it * a command is provided? edit it so it fit your system and run it with !! * want to add something to your notes? ranges to the rescue: .,'aw >> ~/notes * and so on ... actually the more i know vim, the less i use the shell because i never had to copy/paste anymore. an example: to understand the tagging functionality, i wanted to read the man page from my clone of the openbsd repo. i have a command L defined like this: command -range L ,!xargs locate so i typed this on a line *openbsd*less.1 then i use command :L to get /home/mc/src/vendor/openbsd/usr.bin/less/less.1 so i typed !!xargs man and i get the content. this is the kind of shortcuts i use all the time. > The main effect is to lose tagging functionality. > default pager, you cannot use the :t functionality to move to the > place where a word is defined. vim has a very good support of file navigation using ctags. however i don't know what to ctag on and what should be the usage from man. is this the ability to navigate into the manpages? > Yikes. I had no idea what either of these are doing and had to > try them out. vi(1) contains so much bloat that is never really > needed and doesn't belong in a text editor at all. i really consider vim as a multipurpose interactive tui, not an editor. i understand your concern about bloated softwares but i come from a world where colleagues are editing java and python code using ms code (editor based on an html render) to create web applications. so vim is not that bloated. also: reading/writing from/to pipes/buffer gave me a lot of power and spare me the time to find, test and learn new tools to achieve the same. i have only one multipurpose tui i learned and tuned since the last millenium that helps me to edit mails (with spelling), code (with quickfix mode and so on) and some macros i wrote 20 years ago still serves me today. > > feature in openbsd vi. the linux version > > > > map K yw:E /tmp/vi.keyword.$$p!!xargs man > > You don't say what that is supposed to do. sorry. map K yw:E /tmp/vi.keyword.$$p!!xargs man should be read: map K # whenever i press K in normal mode yw# yank the word :E /tmp/vi.keyword.$$ # edit /tmp/vi.keyword.$$ in a new window p # put the word you just pasted in the buffer !!xargs man # filter the current line with xargs man as a result: if the cursor is on the r of the word rctrl and i press K, the manual appears in a new window > Under Debian Jessie, if i start "vim", then type > :map K yw:E /tmp/vi.keyword.$$p!!xargs man > als > K > E132: Function call depth is higher than 'maxfuncdepth' > Press ENTER or type command to continue you can call a map from a map and it seems something like this happens in your case. vim mappings can avoid recursions: use noremap instead of map. however: K is built-in in vim and is much more powerful than my poor macro: * it relies on the 'isk' variable so you can set which chars can be a part of a command * it relies on 'kp' so you can choose an alternative to man to open the doc (perldoc is useful when editing perl code) * the cursor don't need to be on the very first char of the command: anywhere on the command is fine. > I also tried the same with OpenBSD vi(1) and it resulted in > > Usage: e[dit][!] [+cmd] [file]. > > So, no idea what you are trying to do. you have to be on the first letter of the command so instead of als K try als b K > In 2014, i already wrote a patch to do that because the question > came up repeatedly. But demand wasn't that high after all, so i > never committed it. Now, i updated the patch to -current, see > below. i'll try to read this code as soon as possible. > On the one hand, the UNIX phlosophy is to have each tool do one > thing well, then use pipes to connect tools as needed. > arguably, you maybe shouldn't need another tool to just revert > something that the first tool does. > Why would *not* adding backspace > formatting require a pipe to another program, rather than not adding > it in the first place? can't reply on that: out of my skillset :) anyway: thank you very much for taking time help me. regards marc
RE: man to render pure text? (or a pipe in vi macros ?)
Haai, "Ingo Schwarze" wrote: >[about a flag to make mandoc(1) omit backspace stuff:] > In 2014, i already wrote a patch to do that because the question > came up repeatedly. But demand wasn't that high after all, so i > never committed it. Now, i updated the patch to -current, see > below. Medoesn't run -current, so meprolly can't test it, but... > On the one hand, the UNIX phlosophy is to have each tool do one > thing well, then use pipes to connect tools as needed. Then again, > arguably, you maybe shouldn't need another tool to just revert > something that the first tool does. Why would *not* adding backspace > formatting require a pipe to another program, rather than not adding > it in the first place? > > Also, the patch that would be required is very small and straightforward. > > So, what do people think? Should i test the patch below in more > depth and commit it? Or do people consider this bloat? While mecan see much merit in both sides of the argument, me'd say: can't hurt, will help people, go! > Yours, > Ingo Baai, --zeurkous. -- Friggin' Machines!
Re: man to render pure text? (or a pipe in vi macros ?)
dear Ingo, > Absolutely. Using web searches for software documentation is an > awkward and error-prone crutch that should be avoided for many > reasons. For OpenBSD documentation, it is never needed. Actually, the quality of the manpages was one of the reasons i tried openbsd and one of the reasons i emphasize when i try to sell openbsd. > If careful scrutiny of an OpenBSD manual page leaves the impression > that information may be missing from the page, asking on misc@ is > a good idea and often results in an improvement of the manual page. reading both man pages and answers on mailing list makes me aware of other options, features, alternative ways to do things and think about the problems. this is so much enjoyable than copy pasting from a top rated stackoverflow answer. > Only for low-quality software, searching the web may occasionally > be needed. so true. thanks marc
Re: man to render pure text? (or a pipe in vi macros ?)
On Mon, Mar 02, 2020 at 06:25:47PM +0100, Ingo Schwarze wrote: > Hi, > > Marc Chantreux wrote on Mon, Mar 02, 2020 at 11:49:31AM +0100: > > > coming from linux, i'm used to read manpages > > in a vi buffer so i can do much more than > > reading the content. > > I have no idea what the "much more" refers to. The main effect is to > lose tagging functionality. That is, compared to man(1) with the > default pager, you cannot use the :t functionality to move to the > place where a word is defined. > > > i basically use > > > > :r !man ls > > or > > !!sh (when the line content is "man ls") > > Yikes. I had no idea what either of these are doing and had to > try them out. vi(1) contains so much bloat that is never really > needed and doesn't belong in a text editor at all. > > > under openbsd, it seems man doesn't if stdout > > is a tty. > > You mean, man(1) doesn't *imply col -b* if stdout is *not* a tty? > > > i digged the man manual a little bit > > without finding a solution so i worked the > > things around: > > > > :r !man ls|fmt > > As others said, the normal way to strip backspace formatting is > >$ man ls | col -b > > It is documented in man(1) below the -c option and below EXAMPLES, > and in mandoc(1) below "ASCII Output": > > https://man.openbsd.org/man.1#c > https://man.openbsd.org/man.1#EXAMPLES > https://man.openbsd.org/mandoc.1#ASCII_Output > > You find such stuff as follows: > >$ man -k 'Xr=col(1)' > man(1) - display manual pages > mandoc(1) - format manual pages > > The advantage of col(1) over fmt(1) is that it is guaranteed to not > mess up line breaks. > > > now i would like a poor version of keyword > > feature in openbsd vi. the linux version > > > > map K yw:E /tmp/vi.keyword.$$p!!xargs man > > You don't say what that is supposed to do. > > Under Debian Jessie, if i start "vim", then type > > :map K yw:E /tmp/vi.keyword.$$p!!xargs man > als > K > > i get: > > Error detected while processing function > netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore: > line 30: > E132: Function call depth is higher than 'maxfuncdepth' > Press ENTER or type command to continue > > That doesn't seem useful to me. > > I also tried the same with OpenBSD vi(1) and it resulted in > > Usage: e[dit][!] [+cmd] [file]. > > So, no idea what you are trying to do. > > > becomes > > > > map K yw:E /tmp/vi.keyword.$$p!!xargs -IX sh -c 'man X|fmt' > > > > which doesn't work as | separates 2 vi commands. > > > > i really would like to know one or the two of these: > > > > * is there a way to ask man to deliver pure (non-formatted) text ? > > In 2014, i already wrote a patch to do that because the question > came up repeatedly. But demand wasn't that high after all, so i > never committed it. Now, i updated the patch to -current, see > below. > > On the one hand, the UNIX phlosophy is to have each tool do one > thing well, then use pipes to connect tools as needed. Then again, > arguably, you maybe shouldn't need another tool to just revert > something that the first tool does. Why would *not* adding backspace > formatting require a pipe to another program, rather than not adding > it in the first place? > > Also, the patch that would be required is very small and straightforward. > > So, what do people think? Should i test the patch below in more > depth and commit it? Or do people consider this bloat? > > Yours, > Ingo > > > Index: main.c >
Re: man to render pure text? (or a pipe in vi macros ?)
Hi Marc, Marc Chantreux wrote on Mon, Mar 02, 2020 at 07:07:37PM +0100: > On Mon, Mar 02, 2020 at 12:06:42PM -0500, Raul Miller wrote: >> Alternatively, have you tried using any web searches on this topic? > i have to admit i try to avoid the web for many reasons so i try to > stick to manpages, FAQ, mailing list archives. Absolutely. Using web searches for software documentation is an awkward and error-prone crutch that should be avoided for many reasons. For OpenBSD documentation, it is never needed. If careful scrutiny of an OpenBSD manual page leaves the impression that information may be missing from the page, asking on misc@ is a good idea and often results in an improvement of the manual page. Only for low-quality software, searching the web may occasionally be needed. Yours, Ingo
Re: man to render pure text? (or a pipe in vi macros ?)
hello, On Mon, Mar 02, 2020 at 12:06:42PM -0500, Raul Miller wrote: > Have you looked at: > man col > ? how can you come to the point to read the manpage of a command that doesn't seems to be related to your problem (i was searching something around the man input so i tried troff, mandoc, man, ...). Reading from David, i thought col was mentionned in the man manpage. I just read from a recent source of man.1 and realized my openbsd is just too old. at the line 352: .Dl $ man -T ascii -O width=65 pledge | col -b > And, for that matter, have you looked at >man col | cat -vet | less well ... my idea was to remove noise. not add more. > Alternatively, have you tried using any web searches on this topic? i have to admit i try to avoid the web for many reasons so i try to stick to manpages, FAQ, mailing list archives. for the openbsd one, i use https://marc.info/?l=openbsd-misc thanks for helping. marc
Re: man to render pure text? (or a pipe in vi macros ?)
On 2020-03-02, Marc Chantreux wrote: > i felt dumb reading this as i gave a try to the mandoc man. but i just > double checked: > > man mandoc|col -b|grep -w col > > gives me nothing. $ man mandoc|col -b|grep -w col to col(1) -b instead. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: man to render pure text? (or a pipe in vi macros ?)
Hi, Marc Chantreux wrote on Mon, Mar 02, 2020 at 11:49:31AM +0100: > coming from linux, i'm used to read manpages > in a vi buffer so i can do much more than > reading the content. I have no idea what the "much more" refers to. The main effect is to lose tagging functionality. That is, compared to man(1) with the default pager, you cannot use the :t functionality to move to the place where a word is defined. > i basically use > > :r !man ls > or > !!sh (when the line content is "man ls") Yikes. I had no idea what either of these are doing and had to try them out. vi(1) contains so much bloat that is never really needed and doesn't belong in a text editor at all. > under openbsd, it seems man doesn't if stdout > is a tty. You mean, man(1) doesn't *imply col -b* if stdout is *not* a tty? > i digged the man manual a little bit > without finding a solution so i worked the > things around: > > :r !man ls|fmt As others said, the normal way to strip backspace formatting is $ man ls | col -b It is documented in man(1) below the -c option and below EXAMPLES, and in mandoc(1) below "ASCII Output": https://man.openbsd.org/man.1#c https://man.openbsd.org/man.1#EXAMPLES https://man.openbsd.org/mandoc.1#ASCII_Output You find such stuff as follows: $ man -k 'Xr=col(1)' man(1) - display manual pages mandoc(1) - format manual pages The advantage of col(1) over fmt(1) is that it is guaranteed to not mess up line breaks. > now i would like a poor version of keyword > feature in openbsd vi. the linux version > > map K yw:E /tmp/vi.keyword.$$p!!xargs man You don't say what that is supposed to do. Under Debian Jessie, if i start "vim", then type :map K yw:E /tmp/vi.keyword.$$p!!xargs man als K i get: Error detected while processing function netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore..netrw#Explore: line 30: E132: Function call depth is higher than 'maxfuncdepth' Press ENTER or type command to continue That doesn't seem useful to me. I also tried the same with OpenBSD vi(1) and it resulted in Usage: e[dit][!] [+cmd] [file]. So, no idea what you are trying to do. > becomes > > map K yw:E /tmp/vi.keyword.$$p!!xargs -IX sh -c 'man X|fmt' > > which doesn't work as | separates 2 vi commands. > > i really would like to know one or the two of these: > > * is there a way to ask man to deliver pure (non-formatted) text ? In 2014, i already wrote a patch to do that because the question came up repeatedly. But demand wasn't that high after all, so i never committed it. Now, i updated the patch to -current, see below. On the one hand, the UNIX phlosophy is to have each tool do one thing well, then use pipes to connect tools as needed. Then again, arguably, you maybe shouldn't need another tool to just revert something that the first tool does. Why would *not* adding backspace formatting require a pipe to another program, rather than not adding it in the first place? Also, the patch that would be required is very small and straightforward. So, what do people think? Should i test the patch below in more depth and commit it? Or do people consider this bloat? Yours, Ingo Index: main.c === RCS file: /cvs/src/usr.bin/mandoc/main.c,v retrieving revision 1.247 diff -u -p -r1.247 main.c --- main.c 24 Feb 2020 21:15:05 - 1.247 +++ main.c 2 Mar 2020 17:06:53 - @@ -158,6 +158,7 @@ main(int argc, char *argv[]) /* Search options.
Re: man to render pure text? (or a pipe in vi macros ?)
Have you looked at: man col ? (Especially for the -b option...) And, for that matter, have you looked at man col | cat -vet | less ? Alternatively, have you tried using any web searches on this topic? Thanks, -- Raul On Mon, Mar 2, 2020 at 12:01 PM Marc Chantreux wrote: > > hello, > > > Try the mandoc manual page, man is just a front-end to it. Both > > man/mandoc support -T option and you can specify ascii/utf8 to get the > > formatted page but it still adds all escape sequences. > > indeed, that's why i asked > > > The documentation > > says to pipe the output to col -b to suppress them (I think what you did > > with the alternative fmt command). > > i felt dumb reading this as i gave a try to the mandoc man. but i just > double checked: > > man mandoc|col -b|grep -w col > > gives me nothing. can you please tell me what documentation explicitly refers > to col -b? i can probably learn more from it. > > regards > marc >
Re: man to render pure text? (or a pipe in vi macros ?)
hello, > Try the mandoc manual page, man is just a front-end to it. Both > man/mandoc support -T option and you can specify ascii/utf8 to get the > formatted page but it still adds all escape sequences. indeed, that's why i asked > The documentation > says to pipe the output to col -b to suppress them (I think what you did > with the alternative fmt command). i felt dumb reading this as i gave a try to the mandoc man. but i just double checked: man mandoc|col -b|grep -w col gives me nothing. can you please tell me what documentation explicitly refers to col -b? i can probably learn more from it. regards marc
Re: man to render pure text? (or a pipe in vi macros ?)
> It's the designated tool for the job. That fmt also happens to > replace sequences character1-backspace-character2 with character2 > is more of a lucky coincidence. ok then ... good to know. so by extension: by design, there is no way to use the man command to render the text directly? regards, marc
Re: man to render pure text? (or a pipe in vi macros ?)
On Mon, Mar 02, 2020 at 11:49:31AM +0100, Marc Chantreux wrote: > hello, > > coming from linux, i'm used to read manpages > in a vi buffer so i can do much more than > reading the content. i basically use > > :r !man ls > or > !!sh (when the line content is "man ls") > > under openbsd, it seems man doesn't if stdout > is a tty. i digged the man manual a little bit > without finding a solution so i worked the > things around: Try the mandoc manual page, man is just a front-end to it. Both man/mandoc support -T option and you can specify ascii/utf8 to get the formatted page but it still adds all escape sequences. The documentation says to pipe the output to col -b to suppress them (I think what you did with the alternative fmt command). There is an interesting markdown output that seems to work a little bit better in your case. Example: :r!man -T markdown ls But it still not raw. > :r !man ls|fmt To be honest, I think the easiest in that case is to simply add an alias/helper in your shell like viman: #!/bin/sh man "$@" | col -b In vim: :r!viman ls Tested, it worked like a charm. HTH, -- David
Re: man to render pure text? (or a pipe in vi macros ?)
Marc Chantreux: > > > * is there a way to ask man to deliver pure (non-formatted) text ? > > Pipe its output through "col -b". > > what is the gain of using col over fmt ? It's the designated tool for the job. That fmt also happens to replace sequences character1-backspace-character2 with character2 is more of a lucky coincidence. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: man to render pure text? (or a pipe in vi macros ?)
hello, > > * is there a way to ask man to deliver pure (non-formatted) text ? > Pipe its output through "col -b". what is the gain of using col over fmt ? > > * is there a way to introduce a | in vi macros? > Yes, by prefixing it with a ^V character. To enter ^V in vi's input > mode, press control-V twice. grmbl ... how could i have missed this one ... thank you! regards marc
Re: man to render pure text? (or a pipe in vi macros ?)
Marc Chantreux: > * is there a way to ask man to deliver pure (non-formatted) text ? Pipe its output through "col -b". > * is there a way to introduce a | in vi macros? Yes, by prefixing it with a ^V character. To enter ^V in vi's input mode, press control-V twice. -- Christian "naddy" Weisgerber na...@mips.inka.de
