Re: vi: How to display German umlauts?
Dear Martin Am 2024-07-14 20:57, schrieb Martin Schröder: I assume it's https://en.wiktionary.org/wiki/not_in_Kansas_anymore Ah, I see. Makes sense. Thank you for this information! Best regards Rolf
Re: vi: How to display German umlauts?
Am Sa., 13. Juli 2024 um 13:58 Uhr schrieb : > Am 2024-07-11 05:25, schrieb ropers: > > They were all just the chars in some 256-character charset. However, > > you're prolly not in Kansas, and they're not identical in most > > Unicode formats anymore. > > Sorry, but I don't understand the meaning of "However, you're > [probably] not in Kansas". I assume it's https://en.wiktionary.org/wiki/not_in_Kansas_anymore Best Martin
Re: vi: How to display German umlauts?
Dear Crystal Am 2024-07-11 07:09, schrieb Crystal Kolipe: Regarding the OP's specific question - if the files being edited only contain those specific UTF-8 sequences and are otherwise plain ASCII text, then a simple work-around might be a script that replaces each two-byte sequence with the corresponding ISO-8859-1 character, writes that to a temporary file, invokes vi for editing the temporary file, then converts it back to UTF-8 afterwards. Thanks a lot for your suggestion. Indeed, my vi-files contain those 6 specific UTF-8 sequences only. I have seen these 6 sequences are displayed as umlauts when I open the vi files in LibreOffice, and when I convert the vi files to html via asciidoctor. Therefore, I consider it merely a "cosmetical" problem in vi and can do without a script and without nvi - and stick a bit closer to the OpenBSD base install :) Best regards Rolf
Re: vi: How to display German umlauts?
Am 2024-07-11 05:25, schrieb ropers: Dear Ian What vi(1) displays there are (the hex equivalents of) UTF-8 code units. Whenever old vi(1) Can't Even, it will barf hex, but treat each hex-barf byte as a separate character, even when--as here--the two bytes are but one character. Dunning-Kruger applies: Old vi(1) is ignorant of UTF-8 multi-byte characters and unaware of it. In case you are not familiar with the difference between code points and code units, and how to convert from the former to the latter (and vice versa), Graham Douglas has you covered. This page is an excellent resource and might help you wrap your head around that: http://www.readytext.co.uk/?p=1284 Thanky you very much for your explanations and the link. Much appreciated! If there's something like an open mike at EuroBSDcon, and IFF they let me in without signing over my firstborn, perhaps that might be a good place to raise such an issue anyway? And, by the way, your writing style is a pleasure to read :) They were all just the chars in some 256-character charset. However, you're prolly not in Kansas, and they're not identical in most Unicode formats anymore. Sorry, but I don't understand the meaning of "However, you're [probably] not in Kansas". Best regards Rolf
Re: vi: How to display German umlauts?
On Thu, Jul 11, 2024 at 06:34:00PM +0100, ropers wrote: > On Thu, 11 Jul 2024 at 06:09, Crystal Kolipe > wrote: > > > On Thu, Jul 11, 2024 at 04:25:33AM +0100, ropers wrote: > > > It's long been a secret wishlist item for me to solicit/reach agreement > > on > > > which 256 (possibly 512) code points might merit inclusion in a minimal > > > > There is already preliminary support for propper UTF-8 handling in the > > framebuffer console on OpenBSD. It's still buggy, but work is on-going. > > > > Thank you very much. That's great news. > > It would be really nice if agreement could reached between all the BSDs > (and possibly other Unix-likes) on which characters to include in a > minimalist 256--or 512--character subset of Unicode. Why? This makes absolutely no sense to me. Talking about a 512 character subset, your thinking seems to be influenced by either VGA hardware or the linux framebuffer console, neither of which is relevant for our purposes. > This would NOT mean OpenBSD's framebuffer console switching to CP1252 or > even adopting CP1252 -- no, OpenBSD would still be adopting UTF-8 and UTF-8 > only, There are several different issues at play here. The wsfont and rasops subsystems already support fonts with > 256 characters. This is the 'graphical' side of things, support for drawing those glyphs. Right now today, you can create a console font with 100,000 glyphs and load it in to the wscons subsystem. Of course, displaying ASCII text will never touch those glyphs, because the only displayable characters are 32 - 126. The framebuffer console is most commonly configured for ISO-8859-1. Try running: $ echo "\0377" # Octal representation of 0xff. and you get y with diaeresis. You can switch to a different NRCS, (National Replacement Character Set), which will pull in characters from beyond codepoint 127 and put them in the 7-bit ASCII range. On a real DEC terminal these glyphs were remapped from 8-bit positions in the proprietary DEC MCS, (which is similar to but not identical to ISO-8859-1). On OpenBSD, the translation to UCS codepoints is handled by tables defined in wsemul_vt100_chars.c. All of the mappings for regular alphabetical characters fall within the 8-bit ISO-8859-1 range, so even at this point you're not needing to go beyond 256. Some of the line-drawing and other graphics characters found in the DEC technical and special graphics sets are mapped to codepoints > 255 on OpenBSD. As a result, with the default spleen font, you won't see these glyphs. But if you add appropriate glyphs and re-compile the kernel, it'll work. For direct access to glyphs past 255, the OpenBSD wscons console provides UTF-8 emulation. For many years that support was broken and nobody noticed, which already suggests to me that interest is limited for using anything more than ASCII or at most ISO-8859-1 on the framebuffer console. https://marc.info/?l=openbsd-tech&m=167734639712745 That bug has been fixed. Others still exist. Work is on-going. But OpenBSD already supports ISO-8859-1 on the framebuffer console. If you have a desire to create your own 8-bit character set to cater for a particular niche case, it's not particularly difficult. You could just add a new control sequence and a new translation table, or modify an existing one. But the future is UTF-8. > however on the question of which of the hundreds of thousands of > Unicode characters might get one of the 256 limited-edition tickets to > "supported on console" prominence, There is no such limitation on OpenBSD. > It is my understanding that going for 512-character framebuffer console > charsets would require forgoing broader compatibility and the possible use > of 16 colours (512-character VGA framebuffer consoles can only do 8 > colours.) Thus limiting the subset to 256 characters seems advisable. This is a VGA hardware limitation. The framebuffer console is capable of pure 24-bit operation. I published patches last year to make it possible to use 256 colours with TERM=xterm-256color, and in fact the machine I am writing this email on has this set right now. > It would be possible to just put the C0 Control Pictures ( > enwp.org/Control_Pictures) there, which might make the plaintext column in > (suitably patched) hex editors slightly more informative (fewer dots, more > identifiable characters) Hexdump in base calls isprint() to decide whether to print the actual character or replace it with a dot. You can see fewer dots today with the following trivial patch: --- display.c.dist Wed Aug 24 04:13:45 2016 +++ display.c Sat Jul 13 09:15:03 2024 @@ -166,7 +166,7 @@ } break; case F_P: - (void)printf(pr->fmt, isprint(*bp) ? *bp : '.'); + (void)printf(pr->fmt, ((*bp & 0x7f) >= 32 && (*bp != 0x7f)) ? *bp : '.'); break; case F_STR: (void)printf(pr->fmt, (char *)bp); > One character I strongly feel should b
Re: [solved]: vi: How to display German umlauts?
Дана 24/07/13 02:18AM, Pontus Stenetorp написа: > I take it you have that function for cases where the number of files > is very large and would not fit the buffer for your shell? Actually, now that I think of it, that might be the reason why I wrote that function using find more than two years ago. For most repositories, there is no difference between using it and plain `wc -l` with a long list of arguments, but if there are a lot of *.c and *.h files in subdirectories of $HOME: $ cd $ wc -l $(find . -name '*.[ch]') E: /bin/mksh: /usr/bin/wc: Argument list too long and it is not shell-specific; it depends on the system variable ARG_MAX, which is on OpenBSD: $ getconf ARG_MAX 524288 More on this: https://www.in-ulm.de/~mascheck/various/argmax/
Re: [solved]: vi: How to display German umlauts?
Дана 24/07/12 08:50PM, Страхиња Радић написа: > No, I use the version I listed because I can format the output as I see > fit, and it gives per-file statistics. Also, I just now realize this is a case of a "useless use of awk"; I have no idea why I overlooked that wc -l *.c also gives the "total" line and the per-file statistics, and made an awk script to process the wc output. Huh. ¯\_(ツ)_/¯
Re: [solved]: vi: How to display German umlauts?
Дана 24/07/13 02:18AM, Pontus Stenetorp написа: > Always used: > > wc -l $(find vim90 -name '*.[ch]') > > Which gives roughly the same *rough* estimate: 516,321. > > I take it you have that function for cases where the number of files > is very large and would not fit the buffer for your shell? No, I use the version I listed because I can format the output as I see fit, and it gives per-file statistics. > You can also > group your wc(1) calls by using + as your terminator instead of \;. I know of that. Directories I run this function in usually don't have that many files for the "overhead" of exec'ing another wc is significant.
Re: [solved]: vi: How to display German umlauts?
On Tue 09 Jul 2024, Страхиња Радић wrote:
>
> sourcesize()
> {
> find . -name '*.[ch]' -exec wc -l {} \; |
> awk '{
> size = $1
> f = $2
> sum += size
> printf "%10d %s\n", size, f
> }
> END{
> printf "%10d total\n", sum
> }'
> }
>
> gives
>
> 550599 total
>
> when run in the root of Vim's repository. Aside from being a rough
> estimate (it doesn't distinguish comment lines from real code), that
> includes X11 code and various other features which could be opted out.
Always used:
wc -l $(find vim90 -name '*.[ch]')
Which gives roughly the same *rough* estimate: 516,321.
I take it you have that function for cases where the number of files is very
large and would not fit the buffer for your shell? You can also group your
wc(1) calls by using + as your terminator instead of \;.
Re: vi: How to display German umlauts?
On Thu, 11 Jul 2024 at 06:09, Crystal Kolipe wrote: > On Thu, Jul 11, 2024 at 04:25:33AM +0100, ropers wrote: > > It's long been a secret wishlist item for me to solicit/reach agreement > on > > which 256 (possibly 512) code points might merit inclusion in a minimal > > There is already preliminary support for propper UTF-8 handling in the > framebuffer console on OpenBSD. It's still buggy, but work is on-going. > Thank you very much. That's great news. It would be really nice if agreement could reached between all the BSDs (and possibly other Unix-likes) on which characters to include in a minimalist 256--or 512--character subset of Unicode. (If that too is already underway, I may simply be unaware of it and not up to speed.) Since the traditional charset here is that of ISO-8859-1, and since Windows-1252 is both exceedingly good^H^H^H^H common and a superset of ISO-8859-1, the latter looks like a good starting point. (For avoidance of doubt: By superset of the former charset I mean Windows-1252 includes all the characters (or graphemes) present in ISO-8859-1, though not necessarily in the same order.) Again for avoidance of doubt: This would NOT mean OpenBSD's framebuffer console switching to CP1252 or even adopting CP1252 -- no, OpenBSD would still be adopting UTF-8 and UTF-8 only, however on the question of which of the hundreds of thousands of Unicode characters might get one of the 256 limited-edition tickets to "supported on console" prominence, it may not be the worst of ideas to settle on the ones that are in CP1252. So really, we'd be talking about continuing to support what was in ISO-8859-1, and making sensible industry-standard choices in terms of what other characters to admit to the console club. It is my understanding that going for 512-character framebuffer console charsets would require forgoing broader compatibility and the possible use of 16 colours (512-character VGA framebuffer consoles can only do 8 colours.) Thus limiting the subset to 256 characters seems advisable. Even Windows-1252 still leaves a bunch of its 256 spots "unoccupied", i.e. with no grapheme proffered. Notably Windows-1252 and ISO-8859-1 do not define graphemes for the C0 control code characters. New and proper framebuffer console UTF-8 handling routines could use those spots. It would be possible to just put the C0 Control Pictures ( enwp.org/Control_Pictures) there, which might make the plaintext column in (suitably patched) hex editors slightly more informative (fewer dots, more identifiable characters), but those Control Pictures might have issues in some contexts, i.e. with some consoles/terminal emulators, since at least some X11 fonts render them too wide, so if all the Swiss cheese holes align (enwp.org/Swiss_cheese_model), one Control Picture character can end up two monospaced characters wide -- and while framebuffer console fonts are very much controllable, one wouldn't want a situation where something that looks right in the framebuffer console suddenly looks iffy in xterm (or some other X11 terminal emulator) or vice versa. At the peril of sounding like Agent Smith, terminal text mustn't be allowed to escape the matrix. OTOH, maybe bending over backwards to fix some other font designer's mistake is no use or not worth the squeeze. One character I strongly feel should be included in a common minimalist Unicode subset is the U+FFFD � REPLACEMENT CHARACTER, even though some font and tty combos also render that too wide. The above would leave but a literal handful of spots. Windows maps CP1252's 0x81, 8D, 8F, 90, and 9D spots to C1 control codes, but those too are glyphless, and worse, there are no control pictures for C1 codes, so in terms of glyphs and graphemes these spots remain truly empty. I confess, for a while I thought of harebrained schemes, such as using what remains to implement Impulse Tracker-like continuously character-redefining smooth mouse pointer support ( enwp.org/Text-only#Under_DOS_and_Microsoft_Windows) -- or using two-character pairs for little Puffy or Beastie logos -- however, even given Unicode's Private Use Areas, including characters that are not in Unicode is probably not justifiable. Not to mention I wouldn't know how to actually code that. I should probably stop here, lest more abstruse meanderings make me sound any more sectionable than the above already might. Regarding the OP's specific question - if the files being edited only > contain those specific UTF-8 sequences and are otherwise plain ASCII text, > then a simple work-around might be a script that replaces each two-byte > sequence with the corresponding ISO-8859-1 character, writes that to a > temporary file, invokes vi for editing the temporary file, then converts > it back to UTF-8 afterwards. > That is a pretty neat idea. For some value of "simple", I suppose. :-) Of course, this workaround might break in new and interesting ways once what's in the files is no longer strictly limited to two-byte chara
Re: [solved]: vi: How to display German umlauts?
Dear Anon Loli: > (...) > software should be free, and non-personal information should be free, > too, without any IP or a requirement for a file "LICENSE".. those are > just my 2 cents.. if you don't say something about using or redisributing your software or code then nobody knows and noone can be sure if its allowed to do this or that. Just to make it clear for everyone you can give a statement about these topics. A good place for this statement is to include a file and call it LICENSE. > (...), would you use a open source peace of software that in the README > says "you can use it for whatever you want with no strings attached, > and that's it In the end it is your decision. Whether you want to hide the text down in the README or something else. If you are the creator, it's your work and your rules apply. > I'm not sure about the license thought... as I despise licenses and even > having > a copyleft license like CC is getting on my nerves, ... creative commons (CC) recommend against using their licenses for software. Very similar to most Creative Commons licenses are Permissive software licenses (e.g. Apache 2.0 License or MIT License) But here again: if it is your work then you decide the ways share your work.
Re: vi: How to display German umlauts?
On Thu, Jul 11, 2024 at 04:25:33AM +0100, ropers wrote: > It's long been a secret wishlist item for me to solicit/reach agreement on > which 256 (possibly 512) code points might merit inclusion in a minimal There is already preliminary support for propper UTF-8 handling in the framebuffer console on OpenBSD. It's still buggy, but work is on-going. Regarding the OP's specific question - if the files being edited only contain those specific UTF-8 sequences and are otherwise plain ASCII text, then a simple work-around might be a script that replaces each two-byte sequence with the corresponding ISO-8859-1 character, writes that to a temporary file, invokes vi for editing the temporary file, then converts it back to UTF-8 afterwards.
Re: vi: How to display German umlauts?
On Mon, 8 Jul 2024 at 19:05, wrote: > OpenBSD 7.5: In my vi, German umlauts (diaeresis) are displayed as > follows: > Ä: \xc3\x84 > ä: \xc3\xa4 > Ö: \xc3\x96 > ö: \xc3\xb6 > Ü: \xc3\x9c > ü: \xc3\xbc > > These strings appear to consist of 2 character groups, as pressing `x` > 2 times deletes the complete string. > > In man vi(1), I couldn't find anything concerning the file encoding, > Just because of the way you put that, and at the peril of dumbsplaining Unicode to someone who--generally speaking--quite possibly knows much more than yours truly: What vi(1) displays there are (the hex equivalents of) UTF-8 code units. Whenever old vi(1) Can't Even, it will barf hex, but treat each hex-barf byte as a separate character, even when--as here--the two bytes are but one character. Dunning-Kruger applies: Old vi(1) is ignorant of UTF-8 multi-byte characters and unaware of it. In case you are not familiar with the difference between code points and code units, and how to convert from the former to the latter (and vice versa), Graham Douglas has you covered. This page is an excellent resource and might help you wrap your head around that: http://www.readytext.co.uk/?p=1284 Code points and code units used to be identical in ye olde extended ASCII code pages (like ISO-8859-1, Windows-1252, CP437, etc.), so there weren't even any of these special terms for them back in the day. They were all just the chars in some 256-character charset. However, you're prolly not in Kansas, and they're not identical in most Unicode formats anymore. (Reaching agreement on whether they are to be considered identical in UTF-32, and whether that might mean UTF-32 technically isn't even really a *transformation* format is left as an exercise for interested--if not pugilant--readers.) In the variable-width and frequently multi-byte 8-bit Unicode transformation format UTF-8, code points (U+ thru U+10) can be transformed into anything from one (barely *transformed*, as before) through four 8-bit byte code units. This is done for efficient and ASCII backwards-compatible storage (encoding). Your uppercase A umlaut (LATIN CAPITAL LETTER A WITH DIAERESIS) in code unit form can thus be turned back into its code point form: C3 84 1100 0011 1000 0100 <-- strip leading (110) and continuation byte prefixes (10) 0 0011 00 0100 <-- reformat what remains 000 1100 0100 <-- left-fill with zeroes for complete bytes 1100 0100 00 C4 de-rigueur U+ notation: U+00C4 The umlauts are displayed correctly in xterm. > It's long been a secret wishlist item for me to solicit/reach agreement on which 256 (possibly 512) code points might merit inclusion in a minimal Unicode subset which could then be used to make even ye olde text consoles and console fonts on all the BSDs as Unicode-compatible as they can be. a 256-character subset of UTF-8 > ISO-8859-1 on console Hardware (VGA/BIOS) limitations mean only 256 (possibly 512) characters could make the grade. However--due to personal reasons--I've long been out of it, or rather--confession time--I never got *into* it with OpenBSD as much as I always wanted and would have liked, so due to my never having gotten to the point of "patch productivity", I didn't really even dare ask others for something like that. If there's something like an open mike at EuroBSDcon, and IFF they let me in without signing over my firstborn, perhaps that might be a good place to raise such an issue anyway? Or maybe even to elaborate and dumbsplain UTF-8 and the quirks and history of ASCII, and why RFC 4648 is Considered Harmful, though I rather suspect most of the audience would be way ahead of most of what I might have to say in technical terms, so maybe not. Ian
Re: [solved]: vi: How to display German umlauts?
Дана 24/07/09 07:00PM, Anon Loli написа:
> > All that's missing is the URL to the source code of that wonderful
> > editor... if it exists at all.
> >
>
> It's currently offline, off the internet, as far as I know, it was last hosted
> on my eepsite, but circumstances mandated that I had to take down the epsite
> because the site was outdated and insecure due to the circumstances
> It's not usable and probably won't be as beautiful as Neatvi or Arab-friendly
Right... "circumstances". How convenient.
By the way, this function:
sourcesize()
{
find . -name '*.[ch]' -exec wc -l {} \; |
awk '{
size = $1
f = $2
sum += size
printf "%10d %s\n", size, f
}
END{
printf "%10d total\n", sum
}'
}
gives
550599 total
when run in the root of Vim's repository. Aside from being a rough
estimate (it doesn't distinguish comment lines from real code), that
includes X11 code and various other features which could be opted out.
Anyway, vis[1] (vise(1) in OpenBSD: `pkg_add vis`) has some of the
functionality I mentioned earlier, and supports Unicode. The above
function gives
28927 total
for vis.
[1]: https://github.com/martanne/vis
Re: [solved]: vi: How to display German umlauts?
On Tue, Jul 09, 2024 at 08:20:53PM +0200, Страхиња Радић wrote: > Дана 24/07/09 04:02PM, Anon Loli написа: > > That's why I use vi, and am working on my own text editor.. I don't know if > > it'll ever be good, but I'm aiming for Vi-like simplicity, suckless code > > base > > and Vim-like features (only most useful ones, the rest would be in a > > patch-form, like suckless.org has) > > Also when I said "am working", it's more like "was working and will work on > > it > > again", but I have a problem right now which has paused my programming > > life... > > I'm working on it > > If you're interested, perhaps one day you'll want to test it out.. > > All that's missing is the URL to the source code of that wonderful > editor... if it exists at all. > It's currently offline, off the internet, as far as I know, it was last hosted on my eepsite, but circumstances mandated that I had to take down the epsite because the site was outdated and insecure due to the circumstances It's not usable and probably won't be as beautiful as Neatvi or Arab-friendly I'm hesitant to upload it anywhere before I setup my site.. I want to have SOME reputaiton or something, and for that I need my website back online When I put it back online, I'm thinking about making it something similar to cGit, but without git, instead my own version control system and stuff... Ideally I'd want my site written in C, and since it would be minimalistic, that should be easy TLS/SSL is replaced/handled by I2P so one less thing to worry about
Re: [solved]: vi: How to display German umlauts?
Дана 24/07/09 04:02PM, Anon Loli написа: > That's why I use vi, and am working on my own text editor.. I don't know if > it'll ever be good, but I'm aiming for Vi-like simplicity, suckless code base > and Vim-like features (only most useful ones, the rest would be in a > patch-form, like suckless.org has) > Also when I said "am working", it's more like "was working and will work on it > again", but I have a problem right now which has paused my programming life... > I'm working on it > If you're interested, perhaps one day you'll want to test it out.. All that's missing is the URL to the source code of that wonderful editor... if it exists at all.
Re: [solved]: vi: How to display German umlauts?
On Tue, Jul 09, 2024 at 06:36:46PM +0200, prx wrote: > > > Le 9 juillet 2024 18:02:31 GMT+02:00, Anon Loli a > écrit : > >On Tue, Jul 09, 2024 at 12:38:02PM +0200, rfab...@mhsmail.ch wrote: > >> Dear Страхиња Радић, > >> dear Jan, > >> dear Christian > >> > >> Thanks a lot for your prompt and helpful answers! > >> > >> --- > >> Am 2024-07-08 20:35, schrieb Страхиња Радић: > >> > vi lacks a lot of built-in quality of life features that Vim has. > >> > >> Yes, I know Vim from Arch Linux. But for OpenBSD, I'd like to try to > >> stick to the base install as close as possible. > >> > >> --- > >> Am 2024-07-08 21:05, schrieb Jan Stary: > >> > On Jul 08 18:55:11, rfab...@mhsmail.ch wrote: > >> > > As I'd rather not switch to vim, I'd be very grateful for any tips > >> > > concerning the display of umlauts in vi. > >> > > >> > vi can't do it. > >> > >> Thanks for confirming, Jan! > >> > >> --- > >> Am 2024-07-08 22:07, schrieb Christian Weisgerber: > >> > There's a port and package of nvi-2.2.1, which is a close relative > >> > of the base system nvi that has been extended with wide character > >> > support. > >> > >> I have just installed nvi, and the umlauts are displayed correctly. > >> Many thanks for this tip! > >> > >> --- > >> I'm very grateful for the help misc@openbsd.org offers. A big thank > >> you to all the list contributors - and of course to all the contributors > >> and committers of OpenBSD itself. My family and I are very happy > >> to be able to use it for our daily home office work. > >> > >> Best regards > >> > >> Rolf > >> > >> > >> > >> > > > >Once upon a time I decided to take a look at Vim source code > >I did a wc -l, and it gave me like 70 LOC of *.c and *.h files like what > >the fuck? > >Do you know how much 700k of SLOC is? > >Terry Davis made a reasonably good OS in just 100k of SLOC! > >Very easy to hide malicious stuff like the backdoor that was in xz! > > > >That's why I use vi, and am working on my own text editor.. I don't know if > >it'll ever be good, but I'm aiming for Vi-like simplicity, suckless code base > >and Vim-like features (only most useful ones, the rest would be in a > >patch-form, like suckless.org has) > >Also when I said "am working", it's more like "was working and will work on > >it > >again", but I have a problem right now which has paused my programming > >life... > >I'm working on it > >If you're interested, perhaps one day you'll want to test it out.. > > > >I'm not sure about the license thought... as I despise licenses and even > >having > >a copyleft license like CC is getting on my nerves, software should be free, > >and non-personal information should be free, too, without any IP or a > >requirement for a file "LICENSE".. those are just my 2 cents.. > >It's a little more complicated than that, let's just say that I don't want > >being required to specify a LICENSE file... I'm just curious about the > >consequences, would you use a open source peace of software that in the > >README > >says "you can use it for whatever you want with no strings attached, and > >that's > >about it."? > > > >I'm probably rambling needlessly again, that's why none care about what I say > > > > Maybe look at neatvi: > => https://github.com/aligrudi/neatvi > > Even if I still prefer nvi and its soft wrapping. > > Oh, wow! That looks hella impressive! My text editor which is ALMOST functional (you can view and go up/down, but not edit files yet, text is in buffer), and is like 600 SLOC, where Neatvi is 8000 SLOC... But my editor doesn't have proper UTF-8 support, highlighting, any real advanced functions, right-left support or those things found in kmap.h, DIGRAPHS. OK, I'm kindof lying when I say it has no highlighting, the cursor is highlighted, and if we're talking escape sequences, that part should be easy and like 50SLOC, depending on language and what-not And the developer of Neatvi seems to be much more advanced than myself, in C. I'm definitely giving Neatvi a try, after checking out it's source code thank you, very much! I still think that I'll make my own thing, I already learnt a whole lot, like techinques for managing arrays/buffers by which I mean memory, which can be useful like everywhere I think that ANY project can be beneficial for the skill/experience Like I never worked with hexidecimal or whatever 0x7f is >>> actually checking out the source code mid-email Dude advanced poll(2) code? Fuck yeah! It's a little sad that by default C PL doesn't highlight for (u)int8-64.. but for Go it does that lol.. Also I'm not sure how safe it is when it comes to handling escape sequences, but I bet that the developer thought of that, he seems advanced I also realize that there's a ton of string manipulation, and the program manages command queries and stuff, it could easily somehow have a command that runs something malicious Honestly I don't even know what I'm looking for... I doubt it'd do a `rm -Rf ~/*` lol and for networking acces
Re: [solved]: vi: How to display German umlauts?
Le 9 juillet 2024 18:02:31 GMT+02:00, Anon Loli a écrit : >On Tue, Jul 09, 2024 at 12:38:02PM +0200, rfab...@mhsmail.ch wrote: >> Dear Страхиња Радић, >> dear Jan, >> dear Christian >> >> Thanks a lot for your prompt and helpful answers! >> >> --- >> Am 2024-07-08 20:35, schrieb Страхиња Радић: >> > vi lacks a lot of built-in quality of life features that Vim has. >> >> Yes, I know Vim from Arch Linux. But for OpenBSD, I'd like to try to >> stick to the base install as close as possible. >> >> --- >> Am 2024-07-08 21:05, schrieb Jan Stary: >> > On Jul 08 18:55:11, rfab...@mhsmail.ch wrote: >> > > As I'd rather not switch to vim, I'd be very grateful for any tips >> > > concerning the display of umlauts in vi. >> > >> > vi can't do it. >> >> Thanks for confirming, Jan! >> >> --- >> Am 2024-07-08 22:07, schrieb Christian Weisgerber: >> > There's a port and package of nvi-2.2.1, which is a close relative >> > of the base system nvi that has been extended with wide character >> > support. >> >> I have just installed nvi, and the umlauts are displayed correctly. >> Many thanks for this tip! >> >> --- >> I'm very grateful for the help misc@openbsd.org offers. A big thank >> you to all the list contributors - and of course to all the contributors >> and committers of OpenBSD itself. My family and I are very happy >> to be able to use it for our daily home office work. >> >> Best regards >> >> Rolf >> >> >> >> > >Once upon a time I decided to take a look at Vim source code >I did a wc -l, and it gave me like 70 LOC of *.c and *.h files like what >the fuck? >Do you know how much 700k of SLOC is? >Terry Davis made a reasonably good OS in just 100k of SLOC! >Very easy to hide malicious stuff like the backdoor that was in xz! > >That's why I use vi, and am working on my own text editor.. I don't know if >it'll ever be good, but I'm aiming for Vi-like simplicity, suckless code base >and Vim-like features (only most useful ones, the rest would be in a >patch-form, like suckless.org has) >Also when I said "am working", it's more like "was working and will work on it >again", but I have a problem right now which has paused my programming life... >I'm working on it >If you're interested, perhaps one day you'll want to test it out.. > >I'm not sure about the license thought... as I despise licenses and even having >a copyleft license like CC is getting on my nerves, software should be free, >and non-personal information should be free, too, without any IP or a >requirement for a file "LICENSE".. those are just my 2 cents.. >It's a little more complicated than that, let's just say that I don't want >being required to specify a LICENSE file... I'm just curious about the >consequences, would you use a open source peace of software that in the README >says "you can use it for whatever you want with no strings attached, and that's >about it."? > >I'm probably rambling needlessly again, that's why none care about what I say > Maybe look at neatvi: => https://github.com/aligrudi/neatvi Even if I still prefer nvi and its soft wrapping.
Re: [solved]: vi: How to display German umlauts?
On Tue, Jul 09, 2024 at 12:38:02PM +0200, rfab...@mhsmail.ch wrote: > Dear Страхиња Радић, > dear Jan, > dear Christian > > Thanks a lot for your prompt and helpful answers! > > --- > Am 2024-07-08 20:35, schrieb Страхиња Радић: > > vi lacks a lot of built-in quality of life features that Vim has. > > Yes, I know Vim from Arch Linux. But for OpenBSD, I'd like to try to > stick to the base install as close as possible. > > --- > Am 2024-07-08 21:05, schrieb Jan Stary: > > On Jul 08 18:55:11, rfab...@mhsmail.ch wrote: > > > As I'd rather not switch to vim, I'd be very grateful for any tips > > > concerning the display of umlauts in vi. > > > > vi can't do it. > > Thanks for confirming, Jan! > > --- > Am 2024-07-08 22:07, schrieb Christian Weisgerber: > > There's a port and package of nvi-2.2.1, which is a close relative > > of the base system nvi that has been extended with wide character > > support. > > I have just installed nvi, and the umlauts are displayed correctly. > Many thanks for this tip! > > --- > I'm very grateful for the help misc@openbsd.org offers. A big thank > you to all the list contributors - and of course to all the contributors > and committers of OpenBSD itself. My family and I are very happy > to be able to use it for our daily home office work. > > Best regards > > Rolf > > > > Once upon a time I decided to take a look at Vim source code I did a wc -l, and it gave me like 70 LOC of *.c and *.h files like what the fuck? Do you know how much 700k of SLOC is? Terry Davis made a reasonably good OS in just 100k of SLOC! Very easy to hide malicious stuff like the backdoor that was in xz! That's why I use vi, and am working on my own text editor.. I don't know if it'll ever be good, but I'm aiming for Vi-like simplicity, suckless code base and Vim-like features (only most useful ones, the rest would be in a patch-form, like suckless.org has) Also when I said "am working", it's more like "was working and will work on it again", but I have a problem right now which has paused my programming life... I'm working on it If you're interested, perhaps one day you'll want to test it out.. I'm not sure about the license thought... as I despise licenses and even having a copyleft license like CC is getting on my nerves, software should be free, and non-personal information should be free, too, without any IP or a requirement for a file "LICENSE".. those are just my 2 cents.. It's a little more complicated than that, let's just say that I don't want being required to specify a LICENSE file... I'm just curious about the consequences, would you use a open source peace of software that in the README says "you can use it for whatever you want with no strings attached, and that's about it."? I'm probably rambling needlessly again, that's why none care about what I say
[solved]: vi: How to display German umlauts?
Dear Страхиња Радић, dear Jan, dear Christian Thanks a lot for your prompt and helpful answers! --- Am 2024-07-08 20:35, schrieb Страхиња Радић: vi lacks a lot of built-in quality of life features that Vim has. Yes, I know Vim from Arch Linux. But for OpenBSD, I'd like to try to stick to the base install as close as possible. --- Am 2024-07-08 21:05, schrieb Jan Stary: On Jul 08 18:55:11, rfab...@mhsmail.ch wrote: As I'd rather not switch to vim, I'd be very grateful for any tips concerning the display of umlauts in vi. vi can't do it. Thanks for confirming, Jan! --- Am 2024-07-08 22:07, schrieb Christian Weisgerber: There's a port and package of nvi-2.2.1, which is a close relative of the base system nvi that has been extended with wide character support. I have just installed nvi, and the umlauts are displayed correctly. Many thanks for this tip! --- I'm very grateful for the help misc@openbsd.org offers. A big thank you to all the list contributors - and of course to all the contributors and committers of OpenBSD itself. My family and I are very happy to be able to use it for our daily home office work. Best regards Rolf
Re: vi: How to display German umlauts?
Jan Stary: > > As I'd rather not switch to vim, I'd be very grateful for any tips > > concerning the display of umlauts in vi. > > vi can't do it. There's a port and package of nvi-2.2.1, which is a close relative of the base system nvi that has been extended with wide character support. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: vi: How to display German umlauts?
On Jul 08 18:55:11, rfab...@mhsmail.ch wrote: > Dear friends > > OpenBSD 7.5: In my vi, German umlauts (diaeresis) are displayed as > follows: > Ä: \xc3\x84 > ä: \xc3\xa4 > Ö: \xc3\x96 > ö: \xc3\xb6 > Ü: \xc3\x9c > ü: \xc3\xbc > > These strings appear to consist of 2 character groups, as pressing `x` > 2 times deletes the complete string. > > In man vi(1), I couldn't find anything concerning the file encoding, > and the vi command `:set all` didn't give me any hints. > > I log into cwm via xenodm and have the line > `export LC_CTYPE="en_US.UTF-8"` in the `~/.xsession` file, as > suggested in `https://www.openbsd.org/faq/faq10.html#locales`. > > The umlauts are displayed correctly in xterm. > > As I'd rather not switch to vim, I'd be very grateful for any tips > concerning the display of umlauts in vi. vi can't do it.
Re: vi: How to display German umlauts?
Дана 24/07/08 06:55PM, rfab...@mhsmail.ch написа: > My reason for preferring sticking to vi: > "Vim is a huge security hole due to all of the unvetted and often > times unnecessary plugins. While that may be true, plugins are not necessary for the proper operation of Vim. > [...] The fact is that vi is plain better and > will help you learn how to deal with problems using command line > tools." vi lacks a lot of built-in quality of life features that Vim has. Just some examples: - digraphs - :qa - ZQ - :split - :bnext and so on...
vi: How to display German umlauts?
Dear friends OpenBSD 7.5: In my vi, German umlauts (diaeresis) are displayed as follows: Ä: \xc3\x84 ä: \xc3\xa4 Ö: \xc3\x96 ö: \xc3\xb6 Ü: \xc3\x9c ü: \xc3\xbc These strings appear to consist of 2 character groups, as pressing `x` 2 times deletes the complete string. In man vi(1), I couldn't find anything concerning the file encoding, and the vi command `:set all` didn't give me any hints. I log into cwm via xenodm and have the line `export LC_CTYPE="en_US.UTF-8"` in the `~/.xsession` file, as suggested in `https://www.openbsd.org/faq/faq10.html#locales`. The umlauts are displayed correctly in xterm. As I'd rather not switch to vim, I'd be very grateful for any tips concerning the display of umlauts in vi. My reason for preferring sticking to vi: "Vim is a huge security hole due to all of the unvetted and often times unnecessary plugins. The fact is that vi is plain better and will help you learn how to deal with problems using command line tools." (https://www.reddit.com/r/openbsd/comments/ealnzl/vi_vs_vim/) Many thanks and best regards Rolf
