Re: Alt-Arrow bindings in termite
On Sat, Apr 18, 2020 at 01:55:16AM -, Grant Edwards wrote: > On 2020-04-18, Derek Martin wrote: > > > Termite emulates an RS-232 terminal--a simple (AKA "dumb") ASCII > > terminal, whereas rxvt has a more complex interface that allows > > sending and receiving a variety of control sequences to represent > > when someone has pressed a key with a modifier key (like Alt) and > > other control functions. > > RS-232 is an electrical standard specifing a connector and voltage > levels. It says nothing about ASCII or anything else about the data > being transmitted. I'm aware of this, but at the same time it's often the case in the tech world, as you are no doubt aware, that terms are overloaded and/or conflated. In ancient times, if you bought say a 300 baud modem, it would often come with a program that called itself an rs-232 terminal (or terminal emulator). It obviously isn't, in the sense that you mean, since it's a piece of software. Those programs generally used that to mean they were dumb terminal emulators. If you look at the web page for termite, it is clearly using the term in that sense. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Going GUI...er
Derek Martin wrote: > Me personally, I just want the ability to render italics, to represent > emphasis. And to be able to read what my boss sent me... whatever it > might be. Yes, I love mutt for its programmability but when you need to see something your boss sent you, I think the best/easiest way is to bounce or save the entire message and display it via an external GUI MUA, rather than saving the html and possibly other attachments and viewing it via an external web browser. But if I had to do it 50 times a day, or reply to those emails with full formatting, the GUI MUA would have to win. Luckily for me, that's not the case. cheers, raf
Re: Alt-Arrow bindings in termite
On 2020-04-18, Derek Martin wrote: > Termite emulates an RS-232 terminal--a simple (AKA "dumb") ASCII > terminal, whereas rxvt has a more complex interface that allows > sending and receiving a variety of control sequences to represent > when someone has pressed a key with a modifier key (like Alt) and > other control functions. RS-232 is an electrical standard specifing a connector and voltage levels. It says nothing about ASCII or anything else about the data being transmitted. Some RS-232 terminals were far more sophisticated than rxvt. Not only did they support the same ANSI command set that rxvt supports, but some also supported sophisticated vector graphics command sets, printing to attached printers, and various other things that rxvt has never dreamed of. -- Grant
Re: Alt-Arrow bindings in termite
On Thu, Apr 16, 2020 at 10:09:29AM -0400, Jaron Kent-Dobias wrote: > Hello, > > I'm trying to replace rxvt-unicode with termite, and am having trouble with > my mutt bindings. Termite emulates an RS-232 terminal--a simple (AKA "dumb") ASCII terminal, whereas rxvt has a more complex interface that allows sending and receiving a variety of control sequences to represent when someone has pressed a key with a modifier key (like Alt) and other control functions. Not sure why you're trying to do this, but I don't think it's going to work. RS232 terminals, IIRC, at most supported a few basic ANSI control codes for cursor movement and text formatting. > I have > > > bind index,pager \e sidebar-prev > > bind index,pager \e sidebar-next > > bind index,pager \e sidebar-open > > which in rxvt-unicode navigates the sidebar with Alt-Up, Alt-Down, > Alt-Return. In termite the sidebar-open binding still works, but neither the > Alt-Up nor the Alt-Down do. The what-key utility gives 'A' and 'B' as the > keypresses associated with them, respectively, but binding 'A' and 'B' to > sidebar-next and -prev don't work. RS232 terminals can send all of the bytes 0-255, which includes the control characters from 0-31 (ctrl-A is 1, ctrl-B is 2, etc...) so the best you're probably going to be able to do here, is identify some control characters you're not using for something else, and map those to your sidebar functions. Your options are limited though. I could be mistaken about all that though--really if there's a mailing list for termite, that's a better place to ask this question. I haven't seen anyone trying to use an RS232 terminal since I had a 9600 baud modem that was like 35 years ago. Even minicom supported vt100 terminal emulation over a serial line... -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: oddity with an attachment
On Fri, Apr 17, 2020 at 04:45:37PM -0700, Kevin J. McCarthy wrote: > On Sat, Apr 18, 2020 at 08:53:56AM +1000, Cameron Simpson wrote: > >However, it _would_ be nice if mutt could be told to look for this > >stuff in places beyond the standard, even as a a special "save > >filename (or this other filename decoded from a guess)". > > Try setting $rfc2047_parameters. Yup, that does it. Thanks! -- Fred Smith -- fre...@fcshome.stoneham.ma.us - The Lord is like a strong tower. Those who do what is right can run to him for safety. --- Proverbs 18:10 (niv) -
Re: oddity with an attachment
On Sat, Apr 18, 2020 at 08:53:56AM +1000, Cameron Simpson wrote: However, it _would_ be nice if mutt could be told to look for this stuff in places beyond the standard, even as a a special "save filename (or this other filename decoded from a guess)". Try setting $rfc2047_parameters. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Going GUI...er
On Fri, Apr 10, 2020 at 01:09:12PM +0100, Sam Kuper wrote: > On Thu, Apr 09, 2020 at 09:32:01AM -0500, Derek Martin wrote: > > On Wed, Apr 08, 2020 at 01:17:12PM +0100, Sam Kuper wrote: > >> On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote: > >>> Sorry, but this is an archaic way of looking at the problem. > >>> People have been doing this for decades now, has become the norm, > >>> common practice, and really it is therefore WE who are being > >>> inconsiderate by not accepting de facto standards that have been > >>> widely adopted for a very long time. > >> > >> I disagree. You have made a "roads were built for cars" argument*: > >> it assumes that today's "de facto standard" trumps historical > >> precedent and considerate behaviour. And by the way, I ignored this point originally, but doesn't it? Even in the case of cars, which you can argue have had deleterious effects on society (but I think there's plenty of support for the counter-argument), we got to where we got to because it was what most people wanted. Technological evolution is about as democratic as it gets... you vote with your dollars, and the most popular solution wins, regardless of the merits. You can assert that a different solution is better, and your argument might be correct on technical merit, but if most people don't agree your correctness is irrelevant; you still lose. Just ask BetaMax. > >> I've nothing against people sending emails with multiple attachments. > >> But expecting the recipient's MUA to parse multiple attachments into > >> some kind of combined document is presumptuous, because clearly not > >> everyone's MUA does this. > > > > There's a HUGE difference. Roads existed for millenia before > > cars. > > The timescale isn't the point. My analogy refers only to your argument > that today's "de facto standard" trumps historical precedent and > considerate behaviour. In this respect, the analogy is accurate. If you're talking about historical precedence then time scale very much is the point. If your historical precedent was 5 minutes old that doesn't make for a compelling argument. If your time scale includes a period when something was not in widespread use, and then suddently it was, that too seems pretty uncompelling. But even so, you're basically saying, "It was this way, and so it must always be; no evolution of technology should be permitted." That's asinine. Assembled email documents became a thing basically as soon as technical limitations which prevented it from being practical were overcome. It was a natural, and I think inevitable, evolution of technology that happened pretty quickly, once critical mass was realized. Basically people made e-mail do what they could already do for quite a long time with books and other physical print media: format text with pictures to provide efficient presentation of information with previously well-established conventions, i.e. precedence. Now delivered to your own inbox. > I *disagree* that by the mid 90s, most GUI MUAs could handle this. I may be off by a few years, and it's fairly difficult to collect data about what e-mail clients supported what features when, but I certainly recall getting tons of complaints about it by the time I was in my first sysadmin job where I also had to do desktop support, which was in 1997. It doesn't really matter. The point is by now, the feature has been available in the vast majority of major e-mail clients for a very long time, and is in widespread use. You can rail against technological evolution if you like, but that doesn't help people get work done. All I'm after is to not have to fight with my tools to get them to show me what everyone else around me can see effortlessly. At that particular thing, Mutt sucks quite a lot. I used to be one of the people who argued vehemently against non-plaintext e-mail. But over time, the arguments against it have largely become moot for most people, and the fact is it IS better, because of its ability to more efficiently (in terms of what is visually rendered, not necessarily in how it is encoded) present other kinds of information besides simple unformatted plain text. Me personally, I just want the ability to render italics, to represent emphasis. And to be able to read what my boss sent me... whatever it might be. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: oddity with an attachment
On 17Apr2020 16:20, Paul Gilmartin wrote: On 2020-04-17, at 16:06:07, Fred Smith wrote: My wife send me mail from aol.com with an attachment. when I received the mail the attachment's filename was gibberish, NOT what she viewed when she sent it: Content-Type: application/pdf Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?utf-8?B?Q09WSUQxOV9OZXdzbGV0dGVyX1Nlbmlvcl9DZW50ZXJfT3BlcmF0aW9uLnBkZg==?=" Content-ID: This is covered by RFC 5335: https://tools.ietf.org/html/rfc5335 I think that specifies what AOL _should_ be doing (or could be doing). But the extended UTF8-xtra syntax _isn't_ RFC2047 as used above. (Besides, there are no nonASCII characters in the underlying filename - it _should_ just appear in the clear, ungarbled.) Also, doesn't RFC5335 require 8-bit clean transport because if explicitly allows (and requires) nonASCII. See section 2: https://tools.ietf.org/html/rfc5335#section-2 [...] This specification describes a change to the email message format that is related to the SMTP message transport change described in the associated document [RFC4952] and [RFC5336], and that allows non-ASCII characters in most email header fields. These changes affect SMTP clients, SMTP servers, mail user agents (MUAs), list expanders, gateways to other media, and all other processes that parse or handle email messages. [...] Happy to have my thinking corrected if it is wrong. Cheers, Cameron Simpson
Re: oddity with an attachment
On 17Apr2020 18:06, Fred Smith wrote: Odd thing with an attachment, can someone advise? My wife send me mail from aol.com with an attachment. when I received the mail the attachment's filename was gibberish, NOT what she viewed when she sent it: Content-Type: application/pdf Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?utf-8?B?Q09WSUQxOV9OZXdzbGV0dGVyX1Nlbmlvcl9DZW50ZXJfT3BlcmF0aW9uLnBkZg==?=" Ok, so that is an RFC2047 encoding of the name "COVID19_Newsletter_Senior_Center_Operation.pdf". However, this is not a supported syntax for the filename parameter. In fact, this use is actually prohibited by RFC2047 in section 5: + An 'encoded-word' MUST NOT appear within a 'quoted-string'. So AOL should not be doing that to your filename. However, it _would_ be nice if mutt could be told to look for this stuff in places beyond the standard, even as a a special "save filename (or this other filename decoded from a guess)". When viewed in mutt (with "v") it was that same name (though truncated). when saved to disk it retained that weird name. I had her resend it to my gmail account where it showed the correct human-readable name. Do you have the corresponding headers from the gmail account? That would be illuminating. Is there something I can do in mutt to deal with attachments with garbled names? (I'm gussing it's mime--or other--encoded and Mutt didn't decode it for me.) You could edit the message with the "e" key and hand modify the header. Of course, you need to know what to call it. Or you could write a small shell script to modify the filename after saving. In fact, _I_ should write that script and post it for reuse. Here are some references: RFC2047 (defining the =?...?= syntax) is here: https://tools.ietf.org/html/rfc2047 and the filenamestring looks like a "encoded-word" surrounded by double quotes; the "encoded word" syntax is here: https://tools.ietf.org/html/rfc2047#section-2 Section 5 of RFC2047 actually prohibits using the "encoded-word" syntax in a quoted string. In section 5: https://tools.ietf.org/html/rfc2047#section-5 it says, after enumerating where you _can_ use it, it then says: + An 'encoded-word' MUST NOT appear within a 'quoted-string'. The Content-Disposition field is defined in RFC2183, here: https://tools.ietf.org/html/rfc2183 and the filename field is described here: https://tools.ietf.org/html/rfc2183#section-2.3 Cheers, Cameron Simpson
Re: oddity with an attachment
On 2020-04-17, at 16:06:07, Fred Smith wrote: > > My wife send me mail from aol.com with an attachment. when I received the > mail the attachment's filename was gibberish, NOT what she viewed > when she sent it: > > Content-Type: application/pdf > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; > filename="=?utf-8?B?Q09WSUQxOV9OZXdzbGV0dGVyX1Nlbmlvcl9DZW50ZXJfT3BlcmF0aW9uLnBkZg==?=" > Content-ID: > This is covered by RFC 5335: https://tools.ietf.org/html/rfc5335 > Is there something I can do in mutt to deal with attachments with > garbled names? (I'm gussing it's mime--or other--encoded and Mutt didn't > decode it for me.) -- gil
oddity with an attachment
Hi! Odd thing with an attachment, can someone advise? My wife send me mail from aol.com with an attachment. when I received the mail the attachment's filename was gibberish, NOT what she viewed when she sent it: Content-Type: application/pdf Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?utf-8?B?Q09WSUQxOV9OZXdzbGV0dGVyX1Nlbmlvcl9DZW50ZXJfT3BlcmF0aW9uLnBkZg==?=" Content-ID: When viewed in mutt (with "v") it was that same name (though truncated). when saved to disk it retained that weird name. I had her resend it to my gmail account where it showed the correct human-readable name. Is there something I can do in mutt to deal with attachments with garbled names? (I'm gussing it's mime--or other--encoded and Mutt didn't decode it for me.) Thanks in advance! Fred -- Fred Smith -- fre...@fcshome.stoneham.ma.us - The Lord detests the way of the wicked but he loves those who pursue righteousness. - Proverbs 15:9 (niv) -
