Re: [dev] [sbase] Defining scope of sbase and ubase
> Everything in the quoted part seems personal preference. I've been managing my vim plugins with git submodules via vim's builtin "packadd" directory structure (~/.config/vim/pack/plugins/start/...). And I can tell you that trying to do anything remotely non-trivial with them is simply not a pleasant experience. Recent example, there's no way to simply rename a submodule (the --name argument to `submodule add`). You need to edit `.gitmodule` file, edit `.git/config` file along with updating the .git symlinks inside the module and `.git/module` and probably who knows what else. At the end, I just `rm -rf` everything and re-cloned all the modules. Maybe in the future git submodule's UI will be better but as of now it's a PITA to use. - NRK
Re: [dev] reading an epub book with less: adventures in text processing
Hi Greg, On 2024-03-09 15:34, Greg Reagle wrote: I have an epub ebook. It is a novel, but when I get this process working, I want to repeat it for any epub ebook. I want to read it, with formatting (such as underline or italics), with less. I am happy to use any software that exists in the process, but I MUST use less in the end to read it. The terminal emulators that I use are usually st, xterm, and termux. All of them are capable of colored text and underlining and so forth, and I want to take advantage of this. Pandoc does a very good job converting epub to html, and it looks good with w3m, however when I use w3m in a pipe, the output is truly *plain* text, meaning there are no escape codes for formatting. Same story with elinks. Is it possible to get either of these programs, or some other program, to dump html to text *with* escape codes? Since I could not get HTML to work, I went with man format. Amazing. Pandoc automatically chooses man format for output based on the '.1' extension in the followingv pandoc --standalone -o City_of_Truth-Morrow.1 City_of_Truth-Morrow.epub Remember to use standalone option or it won't work. Then man --local-file --pager 'less -ir' City_of_Truth-Morrow.1 It looks great! (for text only on a terminal) It has bold and underlined text. From there I can use less 's' command to save the formatted text to a file. There might be a better or more direct way of achieving this goal, but this I what I figured out for now. And the rationale is this: I already know and love less. There is no good reason for me to learn the user interface of a different program like an epub reader or an html reader to read a book that does not have graphics, diagrams, pictures, and/or custom formatting. Just modify your workflow slightly and you are good: Option 1: use w3m pandoc -s -t html City_of_Truth-Morrow.epub | w3m -T text/html Option 2: use man/less pandoc -t man City_of_Truth-Morrow.epub | man -l - Option 3, save as html for future use: pandoc -s -o City_of_Truth-Morrow.html City_of_Truth-Morrow.epub Saves your epub to html. Whenever you want to view it, use your favorite browser, i.e. w3m, with all its features. Option 4: save as man: pandoc -s -t man -o City_of_Truth-Morrow.man City_of_Truth-Morrow.epub Whenever you view it, use: man -l City_of_Truth-Morrow.man - - - Some notes: The reason you loose formatting when saving from less(1) or w3m is, that these programs on purpose do not save the terminal control characters which are doing the markup. Line breaks and terminal control are created on demand, depending on the type and size of the terminal (window) and will display different (weird) when any of this is different from the terminal you (would have) saved them to a file. The -s option (--standalone) option for Pandoc is not required for man page output. For html (and other formats) pandoc outputs only the content, the -s options wraps this into a complete document. Best Regards, Georg
Re: [dev] reading an epub book with less: adventures in text processing
Greg, thanks for this! for some personal tastes/usage cases, this, using pandoc's `-t` option, might be minor-ly simpler: man --local-file --pager 'less -ir' \ <(pandoc --standalone -t man \ 2015.31233.Arab-Geographers-Knowledge-Of-Southern-India.epub) | less and, this deserves to be somewhere like fortune: "I already know and love less.". :) maybe "fortune-mod-fles-pleh"? :) cheers, Greg
Re: [dev] [sbase] Defining scope of sbase and ubase
On Sat, 09 Mar 2024 17:28:49 +0100 Elie Le Vaillant wrote: > Страхиња Радић wrote: > > Compiling all programs into one binary is currently an option, and IMHO it > > should remain an option. > > I fully agree. However, the single binary situation should be improved. > > > Great, combine the two versions of libutil into a single, separate > > libutil repository > > I'm not sure whether or not this is a good idea, because it makes > sbase and ubase dependant upon a separate repository, which needs to > be present in the parent directory for it to build. It'd also make > sbase development cumbersome, because we very frequently change > libutil when we change sbase. Both are developed as one single > project, and patches reflect this. libutil should not be isolated I > think. > > > then have a directory hierarchy like this: > > > > corebox > > ├──sbase (portable only) \ > > ├──ubase (nonportable) depend on libutil.so and/or libutil.a > > ├──xbase (non-POSIX) / > > └──libutil (option to produce .so and/or .a) > > ubase is not only nonportable, it is _linux-specific_. It is also > non-POSIX. I think ubase should be renamed to reflect this. The > distinction between POSIX/non-POSIX is, I think, not very useful. As There are also multiple standards, not just POSIX. For example tar, true, false are not POSIX (tar was removed from POSIX, and true and false are defined only as shell built-in in POSIX), but they are defined in LSB which a propular, but it's a Linux specific standard. Most of POSIX but not all of POSIX is also defined by LSB. > Mattias said, pure POSIX is quite cumbersome, and not very descriptive > as of what you can expect from it. sh and vi are POSIX, but out-of-scope > for sbase (from the TODO), whereas sponge is crucial for sbase (it > allows simpler implementation of -i for sed, which _is_ POSIX, or the > -o flag for sort (POSIX too)) and would thus be excluded from sbase > and put into xbase. sed -i is not POSIX. > > The solution Mattias proposed (having one big repository, a portable > subdir, a linux (and maybe others in the future, like openbsd) subdir > and a Makefile which includes more descriptive sets than POSIX/non-POSIX > (well, it _can_ be used, but it is not enough)) is I think the best to > fix the problem of libutil duplication/drifting away of versions. It > also allows a broader scope without impeding on the goals of sucklessness. > > One supplementary question, more in line with the original question asked > by Roberto E. Vargas Caballero, is: would awk and sh be out-of-scope? > Should we rather try to implement extensions to awk, or follow the > specification > as strictly possible? Should we implement POSIX sh, or some other shell, such > as rc? > Or is it out-of-scope for us to implement a full-blown shell? I really am > not sure. I don't think there is any reason that sbase should implement all of the standard utilities you need, I think it should only be the small tools that you can reasonably write in one file. Large and complicated programs like sh should be it's own project. > > Regards, > Elie Le Vaillant >
Re: [dev] [sbase] Defining scope of sbase and ubase
On 24/03/09 05:28PM, Elie Le Vaillant wrote: > Or is it out-of-scope for us to implement a full-blown shell? I really am > not sure. I think it would be interesting to have "official" suckless versions of all of the mentioned programs, which would at minimum implement their descriptions from POSIX while keeping suckless principles. In cases where POSIX is vague, there is nothing stopping the authors to implement their take on the acceptable behavior of those programs.
Re: [dev] reading an epub book with less: adventures in text processing
On Sat, Mar 09, 2024 at 09:34:12AM -0500, Greg Reagle wrote: > I have an epub ebook. It is a novel, but when I get this process working, I > want to repeat it for any epub ebook. > > I want to read it, with formatting (such as underline or italics), with less. > I am happy to use any software that exists in the process, but I MUST use > less in the end to read it. The terminal emulators that I use are usually > st, xterm, and termux. All of them are capable of colored text and > underlining and so forth, and I want to take advantage of this. > > Pandoc does a very good job converting epub to html, and it looks good with > w3m, however when I use w3m in a pipe, the output is truly *plain* text, > meaning there are no escape codes for formatting. Same story with elinks. > Is it possible to get either of these programs, or some other program, to > dump html to text *with* escape codes? > > Since I could not get HTML to work, I went with man format. Amazing. Pandoc > automatically chooses man format for output based on the '.1' extension in > the followingv > pandoc --standalone -o City_of_Truth-Morrow.1 City_of_Truth-Morrow.epub > Remember to use standalone option or it won't work. Then > man --local-file --pager 'less -ir' City_of_Truth-Morrow.1 > It looks great! (for text only on a terminal) It has bold and underlined > text. From there I can use less 's' command to save the formatted text to a > file. > > There might be a better or more direct way of achieving this goal, but this I > what I figured out for now. And the rationale is this: I already know and > love less. There is no good reason for me to learn the user interface of a > different program like an epub reader or an html reader to read a book that > does not have graphics, diagrams, pictures, and/or custom formatting. > Hi, Maybe mupdf/mutools or the eGhostscript tools o qpdf? -- Kind regards, Hiltjo
[dev] Re: reading an epub book with less: adventures in text processing
On Sat, Mar 9, 2024, at 9:34 AM, Greg Reagle wrote: > I want to read it, with formatting (such as underline or italics), with > less. Or, I would be satisfied with an ebook reader program (either TUI or GUI is fine) that has the same functionality and keys as less. Of course it can have some extra functionality and keys that would be useful specifically for reading or annotating an ebook, just not conflicting with less behavior. I like the idea of a program that is backwards-compatible with less, in terms of functionality and keys. Maybe I will see if I can make a less-compatible branch for something like mupdf.
Re: [dev] [sbase] Defining scope of sbase and ubase
Страхиња Радић wrote: > Compiling all programs into one binary is currently an option, and IMHO it > should remain an option. I fully agree. However, the single binary situation should be improved. > Great, combine the two versions of libutil into a single, separate > libutil repository I'm not sure whether or not this is a good idea, because it makes sbase and ubase dependant upon a separate repository, which needs to be present in the parent directory for it to build. It'd also make sbase development cumbersome, because we very frequently change libutil when we change sbase. Both are developed as one single project, and patches reflect this. libutil should not be isolated I think. > then have a directory hierarchy like this: > > corebox > ├──sbase (portable only) \ > ├──ubase (nonportable) depend on libutil.so and/or libutil.a > ├──xbase (non-POSIX) / > └──libutil (option to produce .so and/or .a) ubase is not only nonportable, it is _linux-specific_. It is also non-POSIX. I think ubase should be renamed to reflect this. The distinction between POSIX/non-POSIX is, I think, not very useful. As Mattias said, pure POSIX is quite cumbersome, and not very descriptive as of what you can expect from it. sh and vi are POSIX, but out-of-scope for sbase (from the TODO), whereas sponge is crucial for sbase (it allows simpler implementation of -i for sed, which _is_ POSIX, or the -o flag for sort (POSIX too)) and would thus be excluded from sbase and put into xbase. The solution Mattias proposed (having one big repository, a portable subdir, a linux (and maybe others in the future, like openbsd) subdir and a Makefile which includes more descriptive sets than POSIX/non-POSIX (well, it _can_ be used, but it is not enough)) is I think the best to fix the problem of libutil duplication/drifting away of versions. It also allows a broader scope without impeding on the goals of sucklessness. One supplementary question, more in line with the original question asked by Roberto E. Vargas Caballero, is: would awk and sh be out-of-scope? Should we rather try to implement extensions to awk, or follow the specification as strictly possible? Should we implement POSIX sh, or some other shell, such as rc? Or is it out-of-scope for us to implement a full-blown shell? I really am not sure. Regards, Elie Le Vaillant
[dev] reading an epub book with less: adventures in text processing
I have an epub ebook. It is a novel, but when I get this process working, I want to repeat it for any epub ebook. I want to read it, with formatting (such as underline or italics), with less. I am happy to use any software that exists in the process, but I MUST use less in the end to read it. The terminal emulators that I use are usually st, xterm, and termux. All of them are capable of colored text and underlining and so forth, and I want to take advantage of this. Pandoc does a very good job converting epub to html, and it looks good with w3m, however when I use w3m in a pipe, the output is truly *plain* text, meaning there are no escape codes for formatting. Same story with elinks. Is it possible to get either of these programs, or some other program, to dump html to text *with* escape codes? Since I could not get HTML to work, I went with man format. Amazing. Pandoc automatically chooses man format for output based on the '.1' extension in the followingv pandoc --standalone -o City_of_Truth-Morrow.1 City_of_Truth-Morrow.epub Remember to use standalone option or it won't work. Then man --local-file --pager 'less -ir' City_of_Truth-Morrow.1 It looks great! (for text only on a terminal) It has bold and underlined text. From there I can use less 's' command to save the formatted text to a file. There might be a better or more direct way of achieving this goal, but this I what I figured out for now. And the rationale is this: I already know and love less. There is no good reason for me to learn the user interface of a different program like an epub reader or an html reader to read a book that does not have graphics, diagrams, pictures, and/or custom formatting.
[dev] Re: dwm: Maybe a combination of columns and grids?
On Thu, Jan 25, 2024, at 2:48 PM, Greg Reagle wrote: > I love the way that the columns patch handles the master area, i.e. the > ability to control its width and number of windows, and that the > windows in the master area take up the full height of the display. In > the stacking area, though, I'd love for those windows to be managed > like a (gapless) grid. In this context gapless does not mean a few > pixels, but a big chunk missing. FYI, I found the centeredmaster [1] patch and I am very happy with it. It does not do exactly what I asked for (quoted above), but it still is very satisfying. [1] https://dwm.suckless.org/patches/centeredmaster/
Re: [dev] [sbase] Defining scope of sbase and ubase
On Sat, 9 Mar 2024 14:53:07 +0100
Страхиња Радић wrote:
> On 24/03/09 12:59AM, Mattias Andrée wrote:
> > I agree, a single repo (or alternatively making libutil it's own repo) is
> > necessary if we want one binary, and I think we do.
>
> Compiling all programs into one binary is currently an option, and IMHO it
> should remain an option. In my own toy distro[1] based on Musl-LFS and using
> sbase and ubase I compile all programs from {s,u}base separately.
>
> The reasons why I consider that beneficial over a single executable include,
> but are not limited to:
>
> - Easier to maintain: if an administrator decides a utility is unnecessary or
> shouldn't be available, it comes down to rm-ing the file vs recompilation
> of
> the entire *box.
>
> - More robust: in case of disk corruption, all of the utilities are
> unavailable
> vs only those affected.
>
> - Fine-grained control: separate programs can be compiled using specific
> compilation options (eg. -g -O0) vs all of the programs sharing compilation
> options.
>
> etc.
>
>
> > Even if submodules was possible, I do not think they are a good solution.
>
> What makes the git submodules not possible?
I haven't actually checked, but it safe to assume that if it is not
already a problem it very well could become one (and it probably is).
If the two libutil implementations have functions with the same names
they cannot both be linked into the same binary. A "solution" would
be to use weak linkage, but then you can run into problems when the
functions that share name do not share behaviour (e.g. have different
prototype or return type).
>
>
> > Using submodules is unpleasant and pointless since all could is under our
> > control. I think submodules should only be used for code that you do not
> > have control over but need the source code for. Either you have separate
> > repos and have normal compile time dependencies (require that the libraries
> > are installed) or you put everything in one place, one repo.
>
> Everything in the quoted part seems personal preference. Git submodules offer
> a
> way to easily establish a hierarchy of git repositories while keeping them as
> separate "units".
Of course these are personal preferences. There aren't any technical problems
using git submodules assuming you can put everything in the same repo.
>
> So the libutil differs in sbase and ubase. Great, combine the two versions of
> libutil into a single, separate libutil repository, then have a directory
> hierarchy like this:
>
> corebox
> ├──sbase (portable only) \
> ├──ubase (nonportable) depend on libutil.so and/or libutil.a
> ├──xbase (non-POSIX) /
> └──libutil (option to produce .so and/or .a)
>
>
>
> [1]: https://strahinja.srht.site/galeb
>
Re: [dev] [sbase] Defining scope of sbase and ubase
On 24/03/09 12:59AM, Mattias Andrée wrote:
> I agree, a single repo (or alternatively making libutil it's own repo) is
> necessary if we want one binary, and I think we do.
Compiling all programs into one binary is currently an option, and IMHO it
should remain an option. In my own toy distro[1] based on Musl-LFS and using
sbase and ubase I compile all programs from {s,u}base separately.
The reasons why I consider that beneficial over a single executable include,
but are not limited to:
- Easier to maintain: if an administrator decides a utility is unnecessary or
shouldn't be available, it comes down to rm-ing the file vs recompilation of
the entire *box.
- More robust: in case of disk corruption, all of the utilities are unavailable
vs only those affected.
- Fine-grained control: separate programs can be compiled using specific
compilation options (eg. -g -O0) vs all of the programs sharing compilation
options.
etc.
> Even if submodules was possible, I do not think they are a good solution.
What makes the git submodules not possible?
> Using submodules is unpleasant and pointless since all could is under our
> control. I think submodules should only be used for code that you do not
> have control over but need the source code for. Either you have separate
> repos and have normal compile time dependencies (require that the libraries
> are installed) or you put everything in one place, one repo.
Everything in the quoted part seems personal preference. Git submodules offer a
way to easily establish a hierarchy of git repositories while keeping them as
separate "units".
So the libutil differs in sbase and ubase. Great, combine the two versions of
libutil into a single, separate libutil repository, then have a directory
hierarchy like this:
corebox
├──sbase (portable only) \
├──ubase (nonportable) depend on libutil.so and/or libutil.a
├──xbase (non-POSIX) /
└──libutil (option to produce .so and/or .a)
[1]: https://strahinja.srht.site/galeb
Re: [dev] [sbase] Defining scope of sbase and ubase
On Sat, 09 Mar 2024 12:10:28 +0100 Eolien55 wrote: > Mattias Andrée wrote: > > I think there should be one directory called "portable" containing only > > tools > > from sbase, and one directory called "linux" containing the tools from ubase > > and maybe even symlinks to the tools in "portable". This structure would > > allow > > us to add implementations for other operating systems as well. If we add > > symlinks to the tools in "portable" to "linux", each directory could have > > it's own makefile. But I'm not sure this is preferable over a single > > Makefile > > in the root directory. > > This is a great idea! Your mail on the other branch is a great idea too. > I think we should have platform-specific libutil for unportable functions > in ubase's libutil (so, linux/libutil, openbsd/libutil and so on, if we > do actually add implementations for other OSes), and a top-level libutil > too. > > This could maybe allow adding platform-agnostic implementations of some utils > (not all because some APIs are so different that it requires full rewrites, > but maybe some, such as clear, stty, tput, or dd maybe). > > I will start hacking on it, and will post the git repository for it > when it builds correctly. > > I'm not sure how you combine two repositories into one while keeping the > history though. git init . git pull git://git.suckless.org/sbase git branch -M master sbase mkdir sbase mv * .gitignore sbase git add . git commit -m 'Move all of sbase into its own directory' git checkout --orphan master git rm -rf . git pull git://git.suckless.org/ubase git branch -M master ubase mkdir ubase mv * .gitignore ubase git add . git commit -m 'Move all of ubase into its own directory' git checkout --orphan master git rm -rf . git pull --allow-unrelated-histories . sbase git pull --allow-unrelated-histories . ubase > > Regards, > Elie Le Vaillant >
Re: [dev] [sbase] Defining scope of sbase and ubase
Mattias Andrée wrote: > I think there should be one directory called "portable" containing only tools > from sbase, and one directory called "linux" containing the tools from ubase > and maybe even symlinks to the tools in "portable". This structure would allow > us to add implementations for other operating systems as well. If we add > symlinks to the tools in "portable" to "linux", each directory could have > it's own makefile. But I'm not sure this is preferable over a single Makefile > in the root directory. This is a great idea! Your mail on the other branch is a great idea too. I think we should have platform-specific libutil for unportable functions in ubase's libutil (so, linux/libutil, openbsd/libutil and so on, if we do actually add implementations for other OSes), and a top-level libutil too. This could maybe allow adding platform-agnostic implementations of some utils (not all because some APIs are so different that it requires full rewrites, but maybe some, such as clear, stty, tput, or dd maybe). I will start hacking on it, and will post the git repository for it when it builds correctly. I'm not sure how you combine two repositories into one while keeping the history though. Regards, Elie Le Vaillant
