Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-23 Thread songbird
David Wright wrote:
...
> One of the most pleasurable times in my career was when our Research
> Computing Advisor thrust a copy of the Green Book into my hands.
> http://www.math.bas.bg/bantchev/place/snobol/gpp-2ed.pdf
> After years of Fortran, this was my first experience of a designed
> computer language, with dynamic allocation of memory, dynamic typing,
> associative arrays, and its claim to fame, pattern matching.
>
> With over 40 years of language development since then, it's probably
> difficult for anyone now to get quite the same buzz from meeting this
> language. (BTW I was never a user of SNOBOL4 itself, but the compiled
> version, SPITBOL, which was much faster, and available to me on IBM
> OS/360 and its successors.) Its pattern matching was very ahead of
> its time.

...

  yes that was one of languages we surveyed in 
the computer language class.  :)  much fun back 
then.  same as lisp, algol, ada, smalltalk, etc.

  i think i still have the green book here 
someplace.

  time marches on and i've mostly retired from 
coding unless i can come up with something that
catches my interest strongly enough to keep me
busy through a winter.  summertime i'm too busy
gardening to put much time into anything 
significant.


  songbird



Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-22 Thread David Wright
On Sun 19 Jul 2020 at 11:35:31 (+), Ajith R wrote:
> 
> > First, there is a somewhat specific question about unspecified
> > substitutions. For all I know about these substitutions, you might
> > actually need XSLT to do them properly.
> 
> The substitution that I had in mind requires referring to characters based on 
> their unicode properties like script, block...
> 
> > I think you should absolutely use perl if it makes you happy.
> > Unix has a pretty interesting collection of various small tools (which
> > "do one thing and do it well" as you may hear), and shells facilitate
> > hooking up their outputs and inputs. Almost as if they were made to do
> > just that.
> 
> I don't prescribe to using a tool for the sake of happiness. With my limited 
> knoweldege I want to select one that is adequate to do the job.
> The subsitution that I wanted in many text files was deleting text from 
> languages other than Malayalam,english and punctuation. This required a 
> program that could match charcters based on their unicode character of block 
> / script. I didn't find anything to suggest that sed could do that. May be, I 
> didn't search properly.
> Did  I miss a utility(including sed) that can do the kind of substitution I 
> mentioned above?

I've always found exploring new languages very invigorating: the
excitement of having new abilities (the modern generation might
call them new superpowers), and the pleasure of learning itself.
I find it rather a shame that enjoyment isn't at least an important
criterion in selecting your programming tools.

One of the most pleasurable times in my career was when our Research
Computing Advisor thrust a copy of the Green Book into my hands.
http://www.math.bas.bg/bantchev/place/snobol/gpp-2ed.pdf
After years of Fortran, this was my first experience of a designed
computer language, with dynamic allocation of memory, dynamic typing,
associative arrays, and its claim to fame, pattern matching.

With over 40 years of language development since then, it's probably
difficult for anyone now to get quite the same buzz from meeting this
language. (BTW I was never a user of SNOBOL4 itself, but the compiled
version, SPITBOL, which was much faster, and available to me on IBM
OS/360 and its successors.) Its pattern matching was very ahead of
its time.

I had to move to Perl4 for two reasons: 1) the flight from mainframes
in academia, in favour of Unix and PCs, meant that Spitbol became
inaccessible for me; 2) Perl, which was developed a few years earlier
than Python, had a reasonable DOS/Extended Memory implementation
available at the time I got my first PC, a 386DX. Perl gave me an
approximation to a Unix shell and its utilities, and the associative
arrays that I required, but its pattern matching was much more limited
than Spitbol's.

By the time Debian was released, I'd been introduced to Python, and
decided that it looked more attractive than making the transition
Perl4→5. I've never regretted it, despite the hiatuses of the 2→3
and Unicode transitions, particularly as Perl seems to be standing
at a fork in the road so much of the time, whereas Python's behaviour
appears to have been more decisive.

As for your choosing which language to learn, I would spend your time
and effort on a language like Perl or Python. You'll probably pick up
utilities like grep and sed with the greatest of ease if you're
familiar with P⁓.

Cheers,
David.



Re: Using .XCompose

2020-07-20 Thread David Wright
On Mon 20 Jul 2020 at 13:20:19 (+), Ajith R wrote:
[> Someone else wrote:]
> > Try again, for firefox-esr (and with a ~/.XCompose file that is not
> > befouled with nonbreaking spaces).
> > 
> > But make one change to the procedure. When you launch firefox-esr, do
> > so like this:
> > 
> > $ env GTK_IM_MODULE=xim firefox-esr
> > 
> > Let us know how that goes.
> 
> I made a fresh install of Debian on an old 32 bit netbook. Before I did 
> anything to the fresh install, I wrote just one line to the .XCompose file:
>  : "a long substitution"
> 
> Using Kite, I tried typing W while holding down the shift key. I got just the 
> letter "a".
> I tried to start firefox using the command above. Fire fox gave the error 
> (firefox-esr:1554): Gtk-WARNING **: 15:05:11:541 : GTK+ suports to output one 
> char only: "a long substitution":  : "a long substitution"
> The error was repeated 8 times (with different timetsamps) before the firefox 
> window came up. When I tried to type W, either the W remained as such or the 
> field showed a list of string starting with W.

Yes, my experiment with multiple characters produced the same warning.
So it's no surprise that it doesn't work. We're trusting to luck that
some applications appear to support it, at least in the case where
certain other conditions hold. What those conditions are—who knows.

> What next steps do you suggest for me? Should I submit a bug report? Where?

Not much point. The obvious reply will be to refer you to the man page:

   "Compose(5)File Formats ManualCompose(5)

NAME
   Compose - X client mappings for multi-key input sequences

DESCRIPTION
   The X library, libX11, provides a simple input method for characters
   beyond those represented on typical keyboards using sequences of key
   strokes that are combined to enter a single character."

↑↑

Whether XKB can support what you're trying to do, I don't know.
Some of the static phenomena you described seem to be entirely
handled by the rendering of Unicode, and the fonts. Where the
dynamic phenomenon I've read about (the modal behaviour of Delete
and Backspace) is supported, I don't know.

My own interference with the keyboard layout is done in console-setup,
not the X configuration. I can refer you back to my first reply and
https://lists.debian.org/debian-user/2019/07/msg00926.html
which gives you the entire contents of my /etc/console-setup/remap.inc
file. Note that it contains strings.

That's the file where I indulge in a little cargo-cult behaviour:
you have to configure it in a console, but previous experience has
suggested that it *might* not work properly when X is even running,
ie I either kill X, or don't startx it.

(You don't need X to test whether your edits worked, of course, so
an efficient workflow cycle of
  edit/dpkg-reconfigure/test/edit/dpkg-reconfigure/test/…
involves using a text-mode editor.)

Cheers,
David.



Re: Using .XCompose

2020-07-20 Thread Greg Wooledge
On Mon, Jul 20, 2020 at 01:20:19PM +, Ajith R wrote:
> I tried to start firefox using the command above. Fire fox gave the error 
> (firefox-esr:1554): Gtk-WARNING **: 15:05:11:541 : GTK+ suports to output one 
> char only: "a long substitution":  : "a long substitution"

> What next steps do you suggest for me? Should I submit a bug report? Where?

Upstream libgtk, sounds like.

 exists and talks about an issue
tracker, but it's a corporate-kindergarten-looking page designed for
"mobile".  Good luck getting anything done there.



Re: Using .XCompose

2020-07-20 Thread Ajith R
Hi,


> Try again, for firefox-esr (and with a ~/.XCompose file that is not
> befouled with nonbreaking spaces).
> 
> But make one change to the procedure. When you launch firefox-esr, do
> so like this:
> 
> $ env GTK_IM_MODULE=xim firefox-esr
> 
> Let us know how that goes.

I made a fresh install of Debian on an old 32 bit netbook. Before I did 
anything to the fresh install, I wrote just one line to the .XCompose file:
 : "a long substitution"

Using Kite, I tried typing W while holding down the shift key. I got just the 
letter "a".
I tried to start firefox using the command above. Fire fox gave the error 
(firefox-esr:1554): Gtk-WARNING **: 15:05:11:541 : GTK+ suports to output one 
char only: "a long substitution":  : "a long substitution"
The error was repeated 8 times (with different timetsamps) before the firefox 
window came up. When I tried to type W, either the W remained as such or the 
field showed a list of string starting with W.

What next steps do you suggest for me? Should I submit a bug report? Where?

Thanks,
ajith



Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-20 Thread mick crane

On 2020-07-19 09:32, to...@tuxteam.de wrote:

On Sat, Jul 18, 2020 at 10:20:00PM +0100, mick crane wrote:

[...]


>Of course, hacking oneliners (with some measure) can be fun and
>help in the language's mastery [...]



they do work tho' and can be astonishingly quick


?

Quick in typing? In thinking? In compile time? In run time?

There's a common misconception that the less letters a program
has the faster it runs.

It's common, but it is a misconception ;-)


run time, was the first time I saw a Perl oneliner somebody gave me.
Can't remember exactly, think was given a template HTML page and a 
directory of images make new HTML pages inserting image address from 
directory.

click done.

mick

--
Key ID4BFEBB31



Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-19 Thread David Christensen
One last point I missed in my previous post -- big files.  Many Perl 
functions and/or libraries expect to do everything in RAM.  This becomes 
a problem when I want to compress, encrypt, save, and checksum 14 GiB 
system drive images using a live drive and a Perl program in computers 
without large amounts of memory (64 GiB?).  So, I ended up writing a 
Perl program that is truly a script -- it formulates and invokes 
gzip(1), ccrypt(1), md5sum(1), and sha256sum(1) commands as required. 
Traditional Bourne shell scripts are ideally suited for such tasks, and 
the syntax can be cleaner than Perl in simple cases.



On 2020-07-19 03:46, Ajith R wrote:


I seem to recall that he puts Perl at the top of the
heap, and notes that Perl compatible regular expressions (PCRE) are
available via libraries in other programming languages.


Thanks for confirming that I didn't make a wrong choice. Programs that claim to 
use PCRE don't support everything that PERL does.


My use of regular expressions is primarily via grep/ egrep and Perl.  I 
am curious to see what Erlang offers.




I wanted to clean many documents (Wikipedia dump) to analyse the Malayalam 
content. As I was not comfortable with scripting, I was looking for some 
prorgam that could remove the foreign language text from the files. As, I could 
find none that could do the job, I had to use a Perl script with the line below 
(among others)

s/[^\p{Block: Malayalam}\p{Block: Basic_Latin}\p{Block: 
General_Punctuation}\s]//g; # remove characters outside the specified unicode 
blocks.

As of now, the simple substitute command of perl is sufficient for my 
requirements. Even that one command appears powerful compared to others.


That sounds like you need lexing and parsing, followed by your desired 
processing.  In simple cases, Perl regular expressions can accomplish 
two or three of those tasks.  But as complexity grows, you will need 
more and more code.  Writing a lexer/ parser in any language is a 
non-trivial task.  I have used the Perl 'LWP' library to parse HTML 4 
pages, but I have not tried to parse HTML 5 and/or Wikipedia pages.  I 
would look for a library:


https://metacpan.org/search?q=parse

https://metacpan.org/search?q=wikipedia


I spent a little time with Raku (formerly Perl 6).  AIUI improving 
regular expressions was a design goal of Perl 6, and features were added 
specifically for parsing.  There is a book dedicated to the subject.  I 
have a friend who put some time into this area, and he seemed impressed:


https://www.apress.com/us/book/9781484232279


David



Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-19 Thread William Michels
Hello Ajith,

Tom Browder suggests taking a look at Raku (née Perl6), and I concur.
While I don't know Malayalam at all, I can write the regex code below
with ease:

> #all code below using the Raku REPL:
> say '0123456789'.chars;
10
> say $/ if '0123456789' ~~ /  \d+ /;
「0123456789」

> #now with Bengali digits:
> say '০১২৩৪৫৬৭৮৯'.chars;
10
> say $/ if '০১২৩৪৫৬৭৮৯' ~~ /  \d+ /;
「০১২৩৪৫৬৭৮৯」

>#now with Malayalam digits:
> say '൦൧൨൩൪൫൬൭൮൯'.chars;
10
> say $/ if '൦൧൨൩൪൫൬൭൮൯' ~~ /  \d+ /;
「൦൧൨൩൪൫൬൭൮൯」


More info here:

https://www.nntp.perl.org/group/perl.perl6.users/2020/06/msg8828.html
https://www.nntp.perl.org/group/perl.perl6.users/2020/06/msg8845.html

HTH, Bill.



On Sun, Jul 19, 2020 at 4:36 AM Ajith R  wrote:
>
> Hi,
>
> > First, there is a somewhat specific question about unspecified
> > substitutions. For all I know about these substitutions, you might
> > actually need XSLT to do them properly.
>
> The substitution that I had in mind requires referring to characters based on 
> their unicode properties like script, block...
>
> > I think you should absolutely use perl if it makes you happy.
> > Unix has a pretty interesting collection of various small tools (which
> > "do one thing and do it well" as you may hear), and shells facilitate
> > hooking up their outputs and inputs. Almost as if they were made to do
> > just that.
>
> I don't prescribe to using a tool for the sake of happiness. With my limited 
> knoweldege I want to select one that is adequate to do the job.
> The subsitution that I wanted in many text files was deleting text from 
> languages other than Malayalam,english and punctuation. This required a 
> program that could match charcters based on their unicode character of block 
> / script. I didn't find anything to suggest that sed could do that. May be, I 
> didn't search properly.
> Did  I miss a utility(including sed) that can do the kind of substitution I 
> mentioned above?
>
> Thanks,
> ajith
>



Re: how u mine 4 utf8 [was Re: Using .XCompose]

2020-07-19 Thread Ajith R
Hi,

Thanks for the suggestion.
No, I don't do unicode scripting regularly. 
My requirment was a one time requirment to analyse frequency of Malayalam text 
to design a keyboard layout.
But sure, I will keep your suggestion in mind if such requirment comes up 
frequently.

ajith



Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-19 Thread Ajith R
Hi,

> First, there is a somewhat specific question about unspecified
> substitutions. For all I know about these substitutions, you might
> actually need XSLT to do them properly.

The substitution that I had in mind requires referring to characters based on 
their unicode properties like script, block...

> I think you should absolutely use perl if it makes you happy.
> Unix has a pretty interesting collection of various small tools (which
> "do one thing and do it well" as you may hear), and shells facilitate
> hooking up their outputs and inputs. Almost as if they were made to do
> just that.

I don't prescribe to using a tool for the sake of happiness. With my limited 
knoweldege I want to select one that is adequate to do the job.
The subsitution that I wanted in many text files was deleting text from 
languages other than Malayalam,english and punctuation. This required a program 
that could match charcters based on their unicode character of block / script. 
I didn't find anything to suggest that sed could do that. May be, I didn't 
search properly.
Did  I miss a utility(including sed) that can do the kind of substitution I 
mentioned above?

Thanks,
ajith



Re: Fw: how u mine 4 utf8 [was Re: Using .XCompose]

2020-07-19 Thread Tom Browder
On Sun, Jul 19, 2020 at 05:47 Ajith R  wrote:

> Hi,
> > Mapping unicode to UTF-8


Ajith, if you deal with unicode scripting you really should look into Raku.
One of its many strengths is it is unicode (utf8) by default and has many
aids built-in for unicode grapheme handling including regexes and grapheme
introspection.

Cheers!

-Tom


Re: how u mine 4 utf8 [was Re: Using .XCompose]

2020-07-19 Thread Ajith R
Hi,


> These two too:

> RFC 3629 - UTF-8, a transformation format of ISO 10646 (14 pages)
> https://tools.ietf.org/html/rfc3629
> 
> The Unicode Consortium. The Unicode Standard.
> http://www.unicode.org/versions/latest/
> 
> In present version 13.0.0 of the latter,
>   * A brief feature summary of UTF-8 (in chapter 2, General Structure)
>   on pages 37-38
> 
>   * on page 124 (in section 3.9) is a chart that I think makes the
>    mapping from unicode code points to UTF-8 especially clear.

>   * Section 3.9 "Unicode Encoding Forms". Formal definitions, if one
>   enjoys that kind of thing.

Thanks for the references especially for giving the page number from the 
unicode standard (which is a pretty long document).

ajith



Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-19 Thread Ajith R
Hi,

> I seem to recall that he puts Perl at the top of the 
> heap, and notes that Perl compatible regular expressions (PCRE) are 
> available via libraries in other programming languages.

Thanks for confirming that I didn't make a wrong choice. Programs that claim to 
use PCRE don't support everything that PERL does.

I wanted to clean many documents (Wikipedia dump) to analyse the Malayalam 
content. As I was not comfortable with scripting, I was looking for some 
prorgam that could remove the foreign language text from the files. As, I could 
find none that could do the job, I had to use a Perl script with the line below 
(among others)

s/[^\p{Block: Malayalam}\p{Block: Basic_Latin}\p{Block: 
General_Punctuation}\s]//g; # remove characters outside the specified unicode 
blocks.

As of now, the simple substitute command of perl is sufficient for my 
requirements. Even that one command appears powerful compared to others.

ajith



Fw: how u mine 4 utf8 [was Re: Using .XCompose]

2020-07-19 Thread Ajith R


Hi,


> Mapping unicode to UTF-8
Thanks for the explanation and the references. I am starting to understand the 
idea. Hopefully, after going through the references everyone has given, I will 
understand it clearly.



> Example 2. Don't know the name of this one. I tell myself it
> represents a velar nasal stop-initial syllable, but I would appreciate
> correction.

> U+0D19


Yes, it is the velar nasal stop, though I don't understand how 'initial 
syllable' qualifies it . It is the same sound represented by 'ng' in king / 
sing. 

Thanks,
ajith



Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-19 Thread tomas
On Sat, Jul 18, 2020 at 10:20:00PM +0100, mick crane wrote:

[...]

> >Of course, hacking oneliners (with some measure) can be fun and
> >help in the language's mastery [...]

> they do work tho' and can be astonishingly quick

?

Quick in typing? In thinking? In compile time? In run time?

There's a common misconception that the less letters a program
has the faster it runs.

It's common, but it is a misconception ;-)

Cheers
-- t


signature.asc
Description: Digital signature


Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-18 Thread David Christensen

On 2020-07-18 02:59, davidson wrote:

On Thu, 16 Jul 2020 Ajith R wrote:

On Thursday 16 July 2020 4:54:09 AM IST davidson wrote:


[snip]

   $ sed 'y/\xc2\xa0/%/' somefile


An off topic question: of sed, awk and perl, if I am to chose one to
learn, which would you suggest. I wanted to do some substitutions. I
read about them and decided on PERL because from what I understood,
it has better support for regular expressions and do almost
everything that sed and awk could do. Have I made the right
decision?


If your focus is regular expressions, then you should read "Mastering 
Regular Expressions", 3rd Edition:


https://www.oreilly.com/library/view/mastering-regular-expressions/0596528124/


The author compares and contrasts regular expression capabilities in 
various tools.  I seem to recall that he puts Perl at the top of the 
heap, and notes that Perl compatible regular expressions (PCRE) are 
available via libraries in other programming languages.



I will also say that I have used Perl for 20+ years, and Perl has 
allowed me to expand my knowledge and skills tremendously.  I have 
accomplished a lot of useful work with Perl.



As the Perl slogan goes, "There is more than one way to do it".  Perl 
delivers.



Another slogan starts with "Perl makes easy things easy", but I have my 
doubts about the second half "makes hard things possible".



20 years ago, Moore's Law ruled.  You bought a new Pentium computer 
every year and a half, and your Perl script ran faster.



Today, Amdahl's Law rules.  You buy a new Core or Ryzen chip every year 
and a half and your Perl script runs at the same speed.



Perl is fundamentally a sequential programming language.  Concurrent 
programming was bolted on with a library, and that library has a huge 
disclaimer:


https://metacpan.org/pod/threads

"WARNING

The "interpreter-based threads" provided by Perl are not the fast,
lightweight system for multitasking that one might expect or hope
for. Threads are implemented in a way that make them easy to misuse.
Few people know how to use them correctly or will be able to provide
help.

The use of interpreter-based threads in perl is officially
discouraged."


Being the lazy, impatient, and over-proud Perl programmer that I am, I 
disregarded the above and have been working on a Perl library for 
multi-threaded flow-based programming.  OMG.  I don't know if I can or 
will succeed.  It is the most difficult Perl code I have ever worked on.



I have experimented with Go in the past.  I plan to start learning 
Erlang shortly.



David



Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-18 Thread mick crane

On 2020-07-18 22:08, to...@tuxteam.de wrote:

On Sat, Jul 18, 2020 at 09:31:29PM +0100, mick crane wrote:

[...]


You see perl one liners and sed mentioned loads more than awk on the
interweb.
Don't know why that is.


ISTR Perl had a bout of onelineritis back in its youth. This tends
to be somewhat detrimental to a language, because people tend to
believe this is the way you program.

Of course, hacking oneliners (with some measure) can be fun and
help in the language's mastery, but really doing serious work in
this way would be akin to writing a book on differential equations
in kōan form.

Cheers
-- t

they do work tho' and can be astonishingly quick
cheers
mick

--
Key ID4BFEBB31



Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-18 Thread tomas
On Sat, Jul 18, 2020 at 09:31:29PM +0100, mick crane wrote:

[...]

> You see perl one liners and sed mentioned loads more than awk on the
> interweb.
> Don't know why that is.

ISTR Perl had a bout of onelineritis back in its youth. This tends
to be somewhat detrimental to a language, because people tend to
believe this is the way you program.

Of course, hacking oneliners (with some measure) can be fun and
help in the language's mastery, but really doing serious work in
this way would be akin to writing a book on differential equations
in kōan form.

Cheers
-- t


signature.asc
Description: Digital signature


Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-18 Thread mick crane

On 2020-07-18 14:56, to...@tuxteam.de wrote:

On Sat, Jul 18, 2020 at 09:59:46AM +, davidson wrote:

On Thu, 16 Jul 2020 Ajith R wrote:
>On Thursday 16 July 2020 4:54:09 AM IST davidson wrote:

[snip]
>>   $ sed 'y/\xc2\xa0/%/' somefile
>
>An off topic question: of sed, awk and perl, if I am to chose one to
>learn, which would you suggest.


Sed (and awk) are much lighter than perl. So if you find yourself
peppering your shell scripts with lots of little calls to "that
other program", you'll be better off with those two.

Perl will be useful if you are doing the heavy lifting in perl
itself. Then it amortizes (I think this goes for both: computer
run time and your brain time).

Cheers
-- t
You see perl one liners and sed mentioned loads more than awk on the 
interweb.

Don't know why that is.
mick
--
Key ID4BFEBB31



Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-18 Thread William Michels
On Sat, Jul 18, 2020 at 3:40 AM Zenaan Harkness wrote:
> # simple version:
> perl -p -i[.bak] -e 's/xxx/yyy/[g];' $(readlink somefile) # readlink is 
> necessary do not clobber symlinks

Speaking as not-an-expert on Raku (née Perl6), you'd write the above
something like:

user@mbook:~$ # One-liner flag set to line-by-line_&_autoprint (-pe)
user@mbook:~$ # "s///" substitute adverb set to global (:g)
user@mbook:~$ echo "aaa xxx ccc" | raku -pe 's:g/xxx/yyy/;'
aaa yyy ccc
user@mbook:~$

On Sat, Jul 18, 2020 at 3:40 AM Zenaan Harkness wrote:
> # hierarchical "find", handle ALL possible interesting filenames, including 
> those that won't display:
> find target/dir -type f -print0 | xargs -0 perl -p -i[.bak] -e 
> 's/xxx/yyy/[g];'
> ```

Again speaking as not-an-expert on Raku (née Perl6), the second half
of the call above doesn't appear too different from your first
example. However, if you want to try your hand at matching a filename
pattern in a directory, you can try the Raku script posted at:

https://examples.p6c.dev/categories/cookbook/09directories/09-06-filenames-matching-pattern.html
https://github.com/Raku/examples/blob/master/categories/cookbook/09directories/09-06-filenames-matching-pattern.p6

YMMV.

HTH, Bill.



Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-18 Thread songbird
Andrei POPESCU wrote:
> On Sb, 18 iul 20, 09:59:46, davidson wrote:
>>=20
>> But first of all, I should reiterate that I lack expertise.
>>=20
>> I lack expertise.
>>=20
>> Second, I have no useful knowledge about real programming languages
>> (such as perl) to declare.
>
> Same disclaimers apply to me.
>=20
>> But as a peer, albeit a thick one who is not a perl-knowing brain
>> wizard, this is my experience:
>
> In my experience you will encounter sed (more often than awk) in shell=20
> scripts, either because some things are difficult or even impossible to=20
> do in pure shell script, or just because the author didn't know any=20
> better.
>
> Learning perl could be useful if you *also* need a real programing=20
> language in which case you might as well consider python (should be=20
> easier to learn).
>
> Kind regards,
> Andrei

  except if you look at python3 pattern matching
stuff and throw up in disgust.

  i saw something recently that might make me 
revisit the topic in python, but until that 
actually gets implemented i will not be talking
much about python and pattern matching.

  i do use sed and awk and other unix standard
tools.  perl has not been needed for anything i've
done but if someone makes a useful tool and it is
done in perl i won't complain as long as it works
and does what the man page says it should do.


  songbird



Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-18 Thread tomas
On Sat, Jul 18, 2020 at 09:59:46AM +, davidson wrote:
> On Thu, 16 Jul 2020 Ajith R wrote:
> >On Thursday 16 July 2020 4:54:09 AM IST davidson wrote:
> 
> [snip]
> >>   $ sed 'y/\xc2\xa0/%/' somefile
> >
> >An off topic question: of sed, awk and perl, if I am to chose one to
> >learn, which would you suggest.

Sed (and awk) are much lighter than perl. So if you find yourself
peppering your shell scripts with lots of little calls to "that
other program", you'll be better off with those two.

Perl will be useful if you are doing the heavy lifting in perl
itself. Then it amortizes (I think this goes for both: computer
run time and your brain time).

Cheers
-- t


signature.asc
Description: Digital signature


Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-18 Thread Andrei POPESCU
On Sb, 18 iul 20, 09:59:46, davidson wrote:
> 
> But first of all, I should reiterate that I lack expertise.
> 
> I lack expertise.
> 
> Second, I have no useful knowledge about real programming languages
> (such as perl) to declare.

Same disclaimers apply to me.
 
> But as a peer, albeit a thick one who is not a perl-knowing brain
> wizard, this is my experience:

In my experience you will encounter sed (more often than awk) in shell 
scripts, either because some things are difficult or even impossible to 
do in pure shell script, or just because the author didn't know any 
better.

Learning perl could be useful if you *also* need a real programing 
language in which case you might as well consider python (should be 
easier to learn).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-18 Thread Zenaan Harkness
I use perl as a "slightly better sed", in particular the following commands I 
just cut and paste and modify for use, for many years now, to do (multi-)file 
search and replace:

```
# simple version:
perl -p -i[.bak] -e 's/xxx/yyy/[g];' $(readlink somefile) # readlink is 
necessary do not clobber symlinks

# hierarchical "find", handle ALL possible interesting filenames, including 
those that won't display:
find target/dir -type f -print0 | xargs -0 perl -p -i[.bak] -e 's/xxx/yyy/[g];'
```

So I am a regular user of perl, and know almost nothing about it :)

Perl is really great, even though I only know literally how to "sed" with it, 
and nothing else.



sed:awk:perl::rock:paper:chainsaw [was Re: Using .XCompose]

2020-07-18 Thread davidson

On Thu, 16 Jul 2020 Ajith R wrote:

On Thursday 16 July 2020 4:54:09 AM IST davidson wrote:


[snip]

   $ sed 'y/\xc2\xa0/%/' somefile


An off topic question: of sed, awk and perl, if I am to chose one to
learn, which would you suggest. I wanted to do some substitutions. I
read about them and decided on PERL because from what I understood,
it has better support for regular expressions and do almost
everything that sed and awk could do. Have I made the right
decision?


This is sort of two questions in one.

First, there is a somewhat specific question about unspecified
substitutions. For all I know about these substitutions, you might
actually need XSLT to do them properly.

But then there is a more general invitation for advice on where to
invest time.

The second one is a little like one mechanic asking another:

  So erm, Carl. What's your signature ugly hack that you like to use
  to fix broken stuff in a totally unprofessional way? Glue? Duct
  tape?  Chewing gum?  I've been using this epoxy stuff for a while
  now, but I've heard some good things about chewing gum. Wanna tell
  me about it?

But first of all, I should reiterate that I lack expertise.

I lack expertise.

Second, I have no useful knowledge about real programming languages
(such as perl) to declare.

But as a peer, albeit a thick one who is not a perl-knowing brain
wizard, this is my experience:

IF

 1. I can fit it in less than 100 characters,
 2. it's a one-off task and
 3. I'm doing it from an interactive unix shell,

then I will sometimes use sed, most frequently to edit configuration
files. But I consider it a strictly write-only language.

Once I've written it, reviewed it carefully, tested that it does what
I intend, then I use it, check the results and forget I ever saw it.

If it gets more complex than that, and especially if I will ever have
to look at it again, then awk is a likely candidate if pattern-action
templates are the way to go and if the input is mere plain text (not
xml or something like that).

But wait. Let's back up a little.

First of all, why am I using sed to edit config files? Seriously, why?

This is like asking why I'm licking the window. Must be because I LIKE
TO LICK THE WINDOW. No accounting for taste, so they say, and they are
correct. Windows are just so delicious.

Yo-yo mastery results from dedication to an absurd hobby, but hey,
people enjoy it. And more power to 'em. It's harmless, which is more
than can be said for sed abuse.

I would probably be better off if I kicked the sed habit and took up
the yo-yo. Maybe learning some awk was a step in the right direction
after all. But what is interesting to me is that it almost seems like
the *more* I learn about unix, the *less* use I find for either one of
sed or awk.

And for whatever my opinion is worth (spoiler: literally less than
zero) I think you should absolutely use perl if it makes you happy.

I suspect, though, that it could be worthwhile to ask yourself why you
*need* to use it, whenever it seems like you do. For example, I ended
up using sed 'y///' because tr is currently *broken*, when faced with
multi-byte characters.

Unix has a pretty interesting collection of various small tools (which
"do one thing and do it well" as you may hear), and shells facilitate
hooking up their outputs and inputs. Almost as if they were made to do
just that.

This has been tonight's edition of Sweeping Generalities. I'm Richard
Blowhard. Thank you for tuning in.

Good night.

--
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower

Re: how u mine 4 utf8 [was Re: Using .XCompose]

2020-07-18 Thread davidson

On Sat, 18 Jul 2020 davidson wrote:

On Thu, 16 Jul 2020 Ajith R wrote:

On Thursday 16 July 2020 4:54:09 AM IST davidson wrote:


[snip]

I recommend two references I found helpful, though I didn't read
either one especially carefully. I mostly just stared at the templates
(the UTF-8 fighters below), repeatedly asked myself "why did they do
it that way?" and then skimmed to confirm guesses.

First, utf-8(7).

$ man 7 utf-8


These two too:

RFC 3629 - UTF-8, a transformation format of ISO 10646 (14 pages)
https://tools.ietf.org/html/rfc3629

The Unicode Consortium. The Unicode Standard.
http://www.unicode.org/versions/latest/

In present version 13.0.0 of the latter,

 * A brief feature summary of UTF-8 (in chapter 2, General Structure)
   on pages 37-38

 * on page 124 (in section 3.9) is a chart that I think makes the
   mapping from unicode code points to UTF-8 especially clear.

 * Section 3.9 "Unicode Encoding Forms". Formal definitions, if one
   enjoys that kind of thing.

[snip]

So given a unicode code point, do this:

1. discard its leading 0 bits,
2. count how many bits you have left (which is how many x you will
   need from the templates below), and
3. pick your UTF-8 fighter:


And pick the shortest one that works. Choosing a longer one will give
invalid result.



1 octet  (7 bits)  0xxx  
2 octets (11 bits) 110x    10xx  
3 octets (16 bits) 1110    10xx    10xx  
4 octets (21 bits)   0xxx  10xx    10xx    10xx  

[snip]

--
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower



UTF-8 Everywhere -- Re: how u mine 4 utf8 [was Re: Using .XCompose]

2020-07-17 Thread Zenaan Harkness
Just in case anyone missed the memo, essential reading [significantly 
beautified since last I looked, looks like some of the structure intent from 
the link at bottom has been usefully incorporated]:

   UTF-8 Everywhere
 Manifesto
   http://utf8everywhere.org/



Found in this dark and dingy corner of the dungeons:
   https://zenaan.github.io/zen/javadoc/zen/lang/string.html



how u mine 4 utf8 [was Re: Using .XCompose]

2020-07-17 Thread davidson

On Thu, 16 Jul 2020 Ajith R wrote:

On Thursday 16 July 2020 4:54:09 AM IST davidson wrote:


[snip]

   $ sed 'y/\xc2\xa0/%/' somefile


An off topic question: of sed, awk and perl, if I am to chose one to
learn, which would you suggest. I wanted to do some substitutions. I
read about them and decided on PERL because from what I understood,
it has better support for regular expressions and do almost
everything that sed and awk could do. Have I made the right
decision?


[interesting question. postponing my answer]


(However, one advantage of using the C-style byte-constants (\xHH)
instead is that it is easy for everyone to see what they are, the
web archive won't replace them with normal spaces, etc.)


Using the Unicode sequence also gives the same advantages, doesn't
it?


Sure. The unicode code points for characters are a slightly more
abstract value for "what they are" than whatever bytes represent them
in some file, it seems to me. Depending on the purpose, this could be
a good difference.


I find it difficult to get the "translation" between the unicode
code values and the hexadecimal/octal representation.


In this case "the hexadecimal/octal representation" is the UTF-8
representation of unicode code points.

My understanding of text handling has a lot of weaknesses and fuzzy
spots that these discussions have made more apparent to me. And the
map from unicode code points to UTF-8 is one of them.

Or at least it was, until yesterday.

I recommend two references I found helpful, though I didn't read
either one especially carefully. I mostly just stared at the templates
(the UTF-8 fighters below), repeatedly asked myself "why did they do
it that way?" and then skimmed to confirm guesses.

First, utf-8(7).

 $ man 7 utf-8

Second, Wikipedia has a not-bad article about UTF-8.

Anyways, here is my ELI5/explainer how to represent a unicode code
point in UTF-8.


Mapping unicode to UTF-8

[If you don't/can't/won't display this with a fixed-width font, like
courier or something, you might prefer to stop reading here. The
references above are pretty good anyways.]

It helps me to notice that the UTF-8 encoding of unicode permits you
to know --whenever you grab some octet of bits-- where that byte
belongs in the following triage based on its Most Significant Bits
(MSBs).

The octet...

 1. represents an entire character on its own (MSB is 0)
 2. is a non-initial byte of a multi-byte character (MSBs are 10)
 3. is the initial byte of an N-byte character with N>1 (MSBs are N 1s trailed 
by a 0)

(Notice that you could rephrase (1-3) above in terms of the position
of the most significant zero bit.)

So given a unicode code point, do this:

 1. discard its leading 0 bits,
 2. count how many bits you have left (which is how many x you will
need from the templates below), and
 3. pick your UTF-8 fighter:

1 octet  (7 bits)  0 x x x  x x x x
2 octets (11 bits) 1 1 0 x  x x x x  1 0 x x  x x x x
3 octets (16 bits) 1 1 1 0  x x x x  1 0 x x  x x x x  1 0 x x  x x x x
4 octets (21 bits) 1 1 1 1  0 x x x  1 0 x x  x x x x  1 0 x x  x x x x  1 0 x 
x  x x x x

Plug the unicode code point's bits into the rightward slots marked
with x in the template, and fill in any remaining more significant
(leftward) bits with zeros.

Synopsis of worked examples below:
[unicode code point]
[unicode representation, stripped of leading zero bits]
[smallest appropriate UTF-8 template]
[UTF-8 representation]

Example 1. Nonbreaking space character

U+00A0

A0
1 0 1 0  0 0 0 0

1 1 0 x  x x x x  1 0 x x  x x x x

C2A0
1 1 0 0  0 0 1 0  1 0 1 0  0 0 0 0


Example 2. Don't know the name of this one. I tell myself it
represents a velar nasal stop-initial syllable, but I would appreciate
correction.

U+0D19

1 1 0 1  0 0 0 1  1 0 0 1

So, we need to fit the 12 bits above into one of the four UTF-8
templates.

The smallest two can only fit 7 and 11 bits respectively, so we'll
need the next larger template, the three-octet one:

1 1 1 0  x x x x  1 0 x x  x x x x  1 0 x x  x x x x

E0B499
1 1 1 0  x x x x  1 0 1 1  0 1 0 0  1 0 0 1  1 0 0 1


Example 3. a malayalam virama (sp?)

U+0D4D

1 1 0 1  0 1 0 0  1 1 0 1


1 1 1 0  x x x x  1 0 x x  x x x x  1 0 x x  x x x x

E0B58D
1 1 1 0  0 0 0 0  1 0 1 1  0 1 0 1  1 0 0 0  1 1 0 1

--
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower

Re: Using .XCompose

2020-07-16 Thread Ajith R
 On Thursday 16 July 2020 5:27:16 AM IST davidson wrote:




> ie, see whether there are nonbreaking spaces in the message body.

> I attach ajith_msgbody_replace_nbsp.txt, which contains a '%'

> character wherever a nonbreaking space was in the original.




Thanks. So, the non-breaking spaces are getting added in the email system.



Re: Using .XCompose

2020-07-16 Thread Ajith R
On Thursday 16 July 2020 4:54:09 AM IST davidson wrote:




> And so you have set up known environmental conditions for subsequent

> tests of that mechanism.

Yes, that was my intention




> which permits me to toggle my keyboard layout between two alternatives

> ("us" and "ru") by striking capslock.




I will do something similar once I get my  keyboard layout working properly.  




> So I am prone to conclude that whatever your layout may have been

> prior to step (1), it was not a dual-layout setup.

> (This relates more to my own curiosity than to your primary concern.)




No it is not. As of now, I am manually loading my Malayalam layout using 

setxkbmap




> And though it does not have to do with the test you are conducting

> here, I do remain curious about whether your day-to-day keymap table

> *does* include such mappings. It is entirely possible that it does.

> 

> I imagine at this point you may be able to work this out for yourself,

> if it interests you.




I checked and did not find the character.




> It is cool you experiment with what you don't understand. That is how

> mistakes are made, and mistakes are the best teacher of all.

That is true




> This is probably a good spot to recommend a coherent and

> comprehensive, well-curated beginner's guide to bash:

> 

>   BashGuide - Greg's Wiki

>   http://mywiki.wooledge.org/BashGuide

> 

> It is a shame if good learning resources are not used.

Will go through







> > 6) The command grep "W" .XCompose | tr $'\xc2\xa0' \! returns 

> > grep "W" .XCompose | tr $'\xc2\xa0' \!

> 

> This does not seem to make any sense. Where is the output?




Sorry for the mistake. The output is 

 : "This replaces W"







> It looks to me like you may have pasted a copy of the command, where

> you meant to paste its output.

Yes, that was the mistake.







> What you seem to be *showing* us, is that the command produced as

> output a copy of itself. But you don't seem to be *saying* this, or

> reasoning as if that were so, since whatever the output was, further

> below you seem inclined to think that it indicated the file contained

> no nonbreaking spaces.




Yes, that was my conclusion.




>   $ sed 'y/\xc2\xa0/%/' somefile

An off topic question: of sed, awk and perl, if I am to chose one to learn, 

which would you suggest. I wanted to do some substitutions. I read about them 

and decided on PERL because from what I understood, it has better support for 

regular expressions and do almost everything that sed and awk could do. Have I 

made the right decision?







> (However, one advantage of using the C-style byte-constants (\xHH)

> instead is that it is easy for everyone to see what they are, the web

> archive won't replace them with normal spaces, etc.)




Using the Unicode sequence also gives the same advantages, doesn't it?

I find it difficult to get the "translation" between the unicode code values 
and 

the hexadecimal/octal representation.







> David Wright I believe explained this one already. But I do agree with

> you that Original Petitioner would be much funnier.

Funny it is. To me, poster was (until a few emails back) a paper with 

something written in it and stuck on wall .




> OP, on the other hand, always conveys meaning in this sort of forum.

Sure, it does.







> But OP, wHaT WoUlD tHe CoMmUnItY tHiNk about your keyboard layout?

> 

> Have you petitioned your local Keyboard Zoning Board for a custom

> keymap easement and filed the necessary declarations?

With your sense of humor, I am unsure of the meaning of the weird casing of 

your sentence. On a serious note, I am unaware of anything like a local 

Keyboard Zoning Board for Kerala / India. Even if one is there, I will tackle 

it later. Anyway, there is no need for any formalities for customising my 

computer.




> I do not know whether you are familiar with what are called "Regular

> Expressions", often abbreviated as regex.

Yes, I know a bit about regex though not an expert. And I had read about sed 

earlier, but haven't used it favouring perl.




> %% B. Any command (grep included) gets its arguments from the shell



>   BashGuide/SpecialCharacters - Greg's Wiki

>   http://mywiki.wooledge.org/BashGuide/SpecialCharacters

This isn't something that I was familiar with. Will read. 




> [end of overly looong exposition]

Thanks for taking the time and the effort to explain




Re: Using .XCompose

2020-07-15 Thread davidson

On Mon, 13 Jul 2020 Greg Wooledge wrote:

On Sat, Jul 11, 2020 at 08:32:34PM +, davidson wrote:

'!' marks the spot of nonbreaking spaces that made it into OP's first
report of odd behavior, upon testing the white scissors XCompose rule:

  $ grep "WHITE SCISSORS"  d-u_xcompose_2020-07-08.nbsp | tr $'\xc2\xa0' \!
 : "✄" U2704 # 
WHITE SCISSORS


Note that tr does not handle multi-character sequences.  If you pass
something like

tr abc xyz

It does *not* look for "abc" sequences and convert only those sequences.
Rather, it looks at single characters.  It converts 'a' to 'x', and 'b'
to 'y', and 'c' to 'z'.

The number of characters in the first pattern is supposed to match the
number of characters in the second pattern, so that there is a 1:1
mapping.


This much, as it happens, I knew.

My intent was to make plain the nonbreaking spaces for the list, and
in particular for the list archives. (Because it appears that the
versions of messages posted in the web-archives do not preserve such
characters.)


GNU tr also does not handle multi-byte *characters* correctly (which
violates POSIX -- it's a known bug).


And *this* I did *not* know. It was my incorrect belief that the two
bytes of tr's first argument would be treated by tr as a single
character.

It wasn't a *firm* belief. I just did not think it through
carefully. Had I wanted it's actual behavior instead, I may have even
expected it. Stopped clock is correct once in a while!

I see now that "info tr" mentions this behavior up-front. (And
indicates that in future tr will support multi-byte characters.)

In the man page tr(1) I see nothing about all this. It simply talks
about "characters", and assumes the reader is some kind of K&R
obsessed mind-reader who knows "Well, of course a 'character' here
just denotes an octet of bits."


So, your tr command actually converts all c2 bytes into ! and all a0
bytes into ! as well.  Not *just* c2a0 pairs.


Thank you for catching all this, and for concise and comprehensive
explanations.

tr's output line was significantly longer than the line it received as
input. I ought to have noticed.


Nevertheless, this is useful as a first pass approximation to say that,
hey, there *might* be a bunch of NBSPs here, and you should take a
closer look.


You are being charitable.

Since it does not (currently) know what characters are when they
aren't composed of single octets, it was the wrong tool for the job.

  sed 'y/\xc2\xa0/!/'

seems to do the right thing.


NBSPs most often result when someone gets lazy and pastes a line
from a web page or from a Microsoft Word/Excel document into a Unix
terminal or X11 application, instead of pasting just the characters
they actually want.  Web pages, especially *older* web pages, often
use NBSPs for primitive formatting.


Noted.

--
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower

Re: Using .XCompose

2020-07-15 Thread davidson

On Wed, 15 Jul 2020 davidson wrote:

[snip]

If you have both the package called "info" and sed installed, like I do

$ dpkg-query -l


Yes, that is correct. I somehow manage to run a system with just three
packages installed... I'm *that* good.

$ dpkg-query -l info sed texinfo-doc-nonfree # Correction


Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion   Architecture Description
+++-===-=--=
ii  info6.5.0.dfsg.1-4+b1 amd64Standalone GNU Info 
documentation browser
ii  sed 4.7-1 amd64GNU stream editor for 
filtering/transforming text
ii  texinfo-doc-nonfree 6.5.0-1   all  texinfo and info 
documentation that is non-free

then you can do

[snip]

--
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower



Re: Using .XCompose

2020-07-15 Thread davidson

On Sun, 12 Jul 2020 Ajith R wrote:


Could you please see if any of the lines in this message too behaves
similarly


ie, see whether there are nonbreaking spaces in the message body.


?


The message body --of the message to which I reply-- I saved in the
file ajith_msgbody.txt, which features in the commands below.

  $ grep '%' ajith_msgbody.txt # verify '%' character absent from original
  $ echo $? # exit status of above command; 1 indicates no match found
  1
  $ sed 'y/\xc2\xa0/%/' ajith_msgbody.txt >ajith_msgbody_replace_nbsp.txt
  $

I attach ajith_msgbody_replace_nbsp.txt, which contains a '%'
character wherever a nonbreaking space was in the original.

--
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower
Hi All,

I will start with what I did in sequence

Using Konsole from my home directory

1)executed setxkbmap -layout us
2)executed xmodmap which gave the following output

xmodmap:% up to 4 keys per modifier, (keycodes in parentheses):

shift% % % %Shift_L (0x32),% Shift_R (0x3e)
lock% % % % Caps_Lock (0x42)
control% % %Control_L (0x25),% Control_R (0x69)
mod1% % % % Alt_L (0x40),% Alt_R (0x6c),% Meta_L (0xcd)
mod2% % % % Num_Lock (0x4d)
mod3% % %%
mod4% % % % Super_L (0x85),% Super_R (0x86),% Super_L (0xce),% Hyper_L (0xcf)
mod5% % % % ISO_Level3_Shift (0x5c),% Mode_switch (0xcb)

3)executed xmodmap -pk > xmm

The file named xmm is attached

4) executed setxkbmap -print which gave the following%

xkb_keymap {
% % % % xkb_keycodes% { include "evdev+aliases(qwerty)" };
% % % % xkb_types% % %{ include "complete"% % % };
% % % % xkb_compat% % { include "complete"% % % };
% % % % xkb_symbols% %{ include "pc+us+inet(evdev)"% % %};
% % % % xkb_geometry% { include "pc(pc104)"% % %};
};

5) execute grep $'\x00A0' .XCompose. All lines from the .XCompose file were 
listed.
So, I replaced the .XCompose file and retyped the three lines (with only space 
typed using the space bar of the kyboardbetween the letters) and executed the 
grep command. Again it returned all lines. So, I replaced .XCompose file with 
just the W line. Again that line was reported by grep. So, I abandoned Kate and 
built one using cat > .XCompose followed by the line  : "This replaces W", 
followed by Enter and Ctrl+D. The grep command returned the line.

I noticed that there is $ sign before the search string, which I couldn't 
understand. I removed it and re-executed the new grep command grep '\x00A0' 
.XCompose. Now it doesn't return the line

6) The command grep "W" .XCompose | tr $'\xc2\xa0' \! returns%
grep "W" .XCompose | tr $'\xc2\xa0' \!

7) I typed W (holding down shift and pressing w). The Konsole (the instance 
from which I issued the command as well as a new instance) did nothing except 
displaying the W. I typed W in Kate with the same result.


Is it safe to say that the .XCompose file doesn't have the nonbreaking spaces?


> You can print all lines of sometextfile which contain them by doing
> this:

> $ grep $'\xc2\xa0' sometextfile

Is the $ just before the search string in single quotes in the grep command 
intentional? If so, what is its significance?


> '!' marks the spot of nonbreaking spaces that made it into OP's first
> report of odd behavior, upon testing the white scissors XCompose rule:

Could you please see if any of the lines in this message too behaves similarly? 
If so, isn't possible that the mail system adds them?%
BTW, I understand that OP refers to me; but, what exactly does it stand for? 
Original Petitioner?

> So those examples, fi and ½, illustrate the difference between
> modification on output and input in English. I can't judge how the OP
> views this, nor whether they are contravening some conventions in
> their own computer culture by trying to make their changes. This
> doesn't even address how a computer responds to a command line
> written in non-latin script.

I am concerned with the internal representation only. That is, I want  
to be replaced with  < U0D4D> . The display of this sequence as a 
ligated conjunct or as three different symbols is dependant on the font the 
user has. Whether this sequence is displayed as the ligated conjunct or as 
three different charcters, it would be read the same. So, there isn't breaking 
of any langauge semantics% or conventions. All this would bring is some ease of 
typing a commonly used conjunct.

> I know knothing about DE menus.
> It would appear from others' posts that DEs can change anything
> and everything.

What does DE stand for?

> May I ask how you happened to find the post about providing linux
> support for the Breton keyboard
> https://dominiko.livejournal.com/20206.html

I found it by searching the net

> Try again, for firefox-esr (and with a ~/.XCompose file that is not
> befouled with nonbreaking spaces).

> But make one change to the procedure. When you launch firefox-esr, do
> so like this:

> $ env GTK_IM_MODULE=xim firefox-esr
> Let us know how that goes.

Yet

Re: Using .XCompose

2020-07-15 Thread davidson

Hi All,

I will start with what I did in sequence

Using Konsole from my home directory

1)executed setxkbmap -layout us


Naturally, since it is after all the topic of your thread, you are
primarily interested in troubleshooting the XCompose mechanism.

And so you have set up known environmental conditions for subsequent
tests of that mechanism.

Because I am dim/one-track-minded, it took me a while to understand
that this is the purpose of step (1) above.


2)executed xmodmap which gave the following output

xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)


I notice in passing that your modifier key setup here is identical to
my own, with one exception,

  lockISO_Next_Group (0x42)

which permits me to toggle my keyboard layout between two alternatives
("us" and "ru") by striking capslock.

I also notice that clobbering my "ru" alternate layout with the
command you issued in step (1) above does not change the output I get
when I issue the command in step (2).

So I am prone to conclude that whatever your layout may have been
prior to step (1), it was not a dual-layout setup.

(This relates more to my own curiosity than to your primary concern.)


3)executed xmodmap -pk > xmm

The file named xmm is attached


In that keymap table I can find no keys that enter nonbreaking spaces.

And though it does not have to do with the test you are conducting
here, I do remain curious about whether your day-to-day keymap table
*does* include such mappings. It is entirely possible that it does.

I imagine at this point you may be able to work this out for yourself,
if it interests you.


4) executed setxkbmap -print which gave the following 

xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us+inet(evdev)"     };
        xkb_geometry  { include "pc(pc104)"     };
};

5) execute grep $'\x00A0' .XCompose. All lines from the .XCompose file
were listed.


Others have pointed out that here you were simply printing *all* lines
in the file.


So, I replaced the .XCompose file and retyped the three lines (with
only space typed using the space bar of the kyboardbetween the
letters) and executed the grep command. Again it returned all
lines. So, I replaced .XCompose file with just the W line. Again
that line was reported by grep. So, I abandoned Kate and built one
using cat > .XCompose followed by the line  : "This replaces W",
followed by Enter and Ctrl+D. The grep command returned the line.


The ineffective grep command in step (5) seems to be a creation of
your own. Perhaps it is a synthesis of

 $ grep $'\xc2\xa0' sometextfile

together with various information independently learned elsewhere.

As others pointed out, it was *nearly* (but crucially not quite) the
effective replacement

 $ grep $'\u00a0' sometextfile

In APPENDICES at the bottom of this message, I make a few observations
about the two (effective) grep commands immediately above.


I noticed that there is $ sign before the search string, which I
couldn't understand. I removed it and re-executed the new grep
command grep '\x00A0' .XCompose. Now it doesn't return the line


Others have given concise explanations. See appendices below for a
longer one.

It is cool you experiment with what you don't understand. That is how
mistakes are made, and mistakes are the best teacher of all.

This is probably a good spot to recommend a coherent and
comprehensive, well-curated beginner's guide to bash:

 BashGuide - Greg's Wiki
 http://mywiki.wooledge.org/BashGuide

It is a shame if good learning resources are not used.


6) The command grep "W" .XCompose | tr $'\xc2\xa0' \! returns 
grep "W" .XCompose | tr $'\xc2\xa0' \!


This does not seem to make any sense. Where is the output?

It looks to me like you may have pasted a copy of the command, where
you meant to paste its output.

What you seem to be *showing* us, is that the command produced as
output a copy of itself. But you don't seem to be *saying* this, or
reasoning as if that were so, since whatever the output was, further
below you seem inclined to think that it indicated the file contained
no nonbreaking spaces.

Anyways, for a number of reasons that particular command line is a
poor method for rendering nonbreaking spaces visible. Greg explained
one of the reasons: tr maps bytes (octets of bits), and doesn't
understand that some characters are composed of more than one octet.

It is good to know your prefered text editor can display nonbreaking
spaces distinctively, and that you know ho

Re: Using .XCompose

2020-07-15 Thread David Wright
On Tue 14 Jul 2020 at 11:19:30 (+), Ajith R wrote:
> On Sun 12 Jul 2020 at 22:50:23 (-0500), David Wright wrote:
> 
> > OK. I wonder whether the problem you're having with using XCompose
> > is that although those three characters   
> > look independent of each other in the file, the keystrokes that
> > generate them might not be. Not having your layout, I don't think
> > I can test whether you get the behaviour I think you do, that
> > when you put the cursor at the beginning of a *typed* line that
> > looks like the next one and press Delete once:
> > ങ്ങ
> > you get
> > ങ
> > whereas I get
> > ്ങ
> > Is that right?
> 
> I am sorry if I didn't explain properly and for not attaching the keyboard 
> layout (I assumed no one would want to  go through the rather boring lines. I 
> am attaching my .XCompose, the layout file in (the variant I wrote is named 
> mal_puthuniraA) , and the keyboard file.
> 
> To get the ligated conjunct using this layout, I type L while holding down 
> Shift followed by f (or j) without shift and then L while holding down Shift. 
> When these characters are typed, the program will show the ligated conjunct 
> form if its font supports the form or else it displays the three characters 
> separately. So, when you go to the beginning of ങ്ങ and press delete once, 
> you should get ്ങ or the entire ങ്ങ is deleted (based on how the program 
> treats the ligated conjnct form).

I haven't found a font that displays three characters corresponding to
the three code points. Even a font that prints blobs only prints two.
And I don't think Delete should ever delete both characters (three
code points) with one press. Even though ligated, there are two
characters there.

> There are issues in displaying ligated forms by various programs and I assume 
> that by extension there will be problems while deleting also. More over, the 
> < ് > is a combining mark. So, some programs will treat the charcter 
> preceeding < ് > and the < ് > as one character.

Yes, it does seem that the "system" knows that, even where it has no
appropriate glyphs available for displaying.

In what follows, you have to bear in mind that I can't actually type
any of these characters, so everything in the command line ultimately
originated as copy/paste from your emails or a code block printout.

I've found it useful to copy this line into the command line for
experimenting:

$ hexdump -C <<<' ങ്ങ '

> In Konsole, the ligated conjunct is formed correctly, but the width 
> calculated for display is slightly off and so the cursor is placed over the 
> character. When I use Home key to go to the beginning of the line and then 
> press Delete, I get ങ്. When I get to the end and press backspace also, I get 
> the same result. If I press back space a second time, the ങ് is deleted. Note 
> that both characters are deleted with one back space. If I move to the 
> beginning of ങ്ങ and then press right arrow once and then press space once, I 
> get ങ് ങ.

Yes, I can't fully explain what's going on when you press Delete once
when at the beginning of the line. What's immediately reflected is the
same as for you, but when I recall the line, I get the consonant ങ alone.
I don't know, of course, which is right. Should it preserve the
"no vowel attached" mark on a solitary consonant or not? Here:

$ hexdump -C <<<' ങ്ങ ' ← constructed with copy/paste
  20 e0 b4 99 e0 b5 8d e0  b4 99 20 0a  | . .|
000c
$ 
$ hexdump -C <<<' ങ് '  ← recalled the line above, and deleted 1st 
char
  20 e0 b4 99 20 0a | ... .|
0006
$ 
$ hexdump -C <<<' ങ '  ← recalled the line above: it's different!
  20 e0 b4 99 20 0a | ... .|
0006
$ 

> In Kate, deleting from the beginning deletes the entire ങ്ങ, backspace from 
> the end deletes the entire one character at one time giving ങ് followed by 
> ങ.Moving to beginning and inserting a space adds the space after ങ്ങ.

In text mode, emacs treats the string as three characters, though two
are displayed, and the cursor behaves as if there were just two.
So if I put the cursor between them and press Backspace, the first
character, both consonant and attached "vowel", gets erased.
However, if I press Delete before the first character, I see  ്ങ
with an exposed "vowel".

In terms of the underlying code points, this seems entirely logical.
The only limitation is that you can't erase (with Backspace) an
attached "vowel" without also erasing the consonant it's attached to.

But in terms of writing running text, it seems to be the wrong way
round, compared with what I've read. It you type a consonant, and then
type the wrong vowel, you ought to be able to erase the vowel and type
another in its place.

> I don't think these variations in handling Indic scripts is related to the 
> problem of Composing. But, please do check the keyboard layout I am attaching.

As I say

Re: Using .XCompose

2020-07-13 Thread Ajith R
Hi David,

> And I assume they're not in the files that you wrote from scratch,
> like .XCompose. Would that be right?

Yes, I couldn't find any in my XCompose file and in the layout file.


> Kate appears to be a normal text editor. The third sentence of its
> official description (https://kate-editor.org/) says "Choose it for
> […], editing configuration files". It doesn't seem to me to be
> like writing text files in, say, Word (a word processor).

I am not sure I understand this correctly.  I know that Kate is plain text 
editor, not something like Word, if that is what you mean

> It would be nice not to get sidetracked by this, and to find out
> whether the way that the Indic Script input system (InScript) works is
> compatible with the composition of characters, which is the purpose of
> .XCompose. (I'm assuming that linux tries to give the >1billion people
> concerned an InScript system that's compatible with other platforms).

I tried thrice to send a reply to your previous message. Those messages are 
shown as being sent, but does not get delivered to me through debian list.
(Earlier, I got a message that there was a bounce and that I would be removed 
if it happens again. I don't know if I have been removed from the list or not.)
I want to repeat that my problem of .XCompose not working is not lmited to 
Indic scripts. It is happening with English too.
BTW, InScript is one layout among many layouts for the various Indian Scripts.


Thanks,
ajith



Re: Using .XCompose

2020-07-13 Thread David Wright
On Mon 13 Jul 2020 at 18:45:45 (+), Ajith R wrote:
> Hi Greg,
> 
> > In it, there is a brief mention of some option you can toggle called
> > "Show Non-Printable Spaces", whose description is "Show/hide bounding
> > box around non-printable spaces."
> 
> Yes, though not very obvious, Kate does show the non breaking sapces with an 
> open box after selecting the option.

And I assume they're not in the files that you wrote from scratch,
like .XCompose. Would that be right?

Kate appears to be a normal text editor. The third sentence of its
official description (https://kate-editor.org/) says "Choose it for
[…], editing configuration files". It doesn't seem to me to be
like writing text files in, say, Word (a word processor).

It would be nice not to get sidetracked by this, and to find out
whether the way that the Indic Script input system (InScript) works is
compatible with the composition of characters, which is the purpose of
.XCompose. (I'm assuming that linux tries to give the >1billion people
concerned an InScript system that's compatible with other platforms).

Cheers,
David.



Re: Using .XCompose

2020-07-13 Thread Ajith R
Hi Greg,

> In it, there is a brief mention of some option you can toggle called
> "Show Non-Printable Spaces", whose description is "Show/hide bounding
> box around non-printable spaces."

Yes, though not very obvious, Kate does show the non breaking sapces with an 
open box after selecting the option.

Thanks,
ajith






Re: Using .XCompose

2020-07-13 Thread Greg Wooledge
On Mon, Jul 13, 2020 at 06:24:58PM +, Ajith R wrote:
> I was trying to find if NBSP are getting added in my .XCompose file
> 
> I am using Kate. How can I accomplish that in Kate?

I googled .  The first result
didn't talk about them at all.  The second result was to a PDF which is
apparently their official documentation.
.

In it, there is a brief mention of some option you can toggle called
"Show Non-Printable Spaces", whose description is "Show/hide bounding
box around non-printable spaces."

I have no idea what they consider to be a "non-printable space".  You
could try it.

> > (I don't even know whether you're in a UTF-8 encoding, though, so
> > who knows whether those are even the correct bytes for an NBSP in>
> > your locale.  You're better off using \u00A0 instead.)
> 
> No, I don't want to use them. Just wanted to know if they were creeping into 
> my file.

I meant use in your bash + grep command.  The earlier attempts to use
$'\x00A0' or $'\x00\xA0' were not correct.



Re: Using .XCompose

2020-07-13 Thread Ajith R
Hi Greg,


> I would imagine you were trying to pass a Unicode character.  If that's
> the case, you need the \u or \U form instead.
> 
> grep $'\u00A0' .XCompose
> 
> Unicode character 00A0 is a non-breaking space.  It's not clear whether
> that was your intention or not.


Yes, that was my intention

> > I noticed that there is $ sign before the search string, which I couldn't 
> > understand. I removed it and re-executed the new grep command grep '\x00A0' 
> > .XCompose. Now it doesn't return the line
> 
> Uh... you mean you *weren't* trying to grep for non-breaking spaces
> in your file using bash's $'...' quoting syntax?  You're just typing
> something you found at random on the Internet without understanding
> it?  That's pretty dangerous.

Yes, I was trying something that I didn't understand. However, it was not from 
the internet but given a pretty helpful person in this group.

>  might be good reading for you at
>  this point.
Thanks, will check it out.


> 6) The command grep "W" .XCompose | tr $'\xc2\xa0' \! returns 
> grep "W" .XCompose | tr $'\xc2\xa0' \!


> The two hex bytes c2 a0 are the UTF-8 encoding of a non-breaking space,
> so it *does* seem like you're chasing after non-breaking spaces for
> some reason

I was trying to find if NBSP are getting added in my .XCompose file

> If that's truly your goal, you might also want to pursue configuring
> your text editor to show them to you.  There are various ways to do
> that, depending on which text editor you use.

I am using Kate. How can I accomplish that in Kate?


> (I don't even know whether you're in a UTF-8 encoding, though, so
> who knows whether those are even the correct bytes for an NBSP in>
> your locale.  You're better off using \u00A0 instead.)

No, I don't want to use them. Just wanted to know if they were creeping into my 
file.

Thanks,
ajith




Re: Using .XCompose

2020-07-13 Thread Greg Wooledge
On Sat, Jul 11, 2020 at 08:32:34PM +, davidson wrote:
> '!' marks the spot of nonbreaking spaces that made it into OP's first
> report of odd behavior, upon testing the white scissors XCompose rule:
> 
>   $ grep "WHITE SCISSORS"  d-u_xcompose_2020-07-08.nbsp | tr $'\xc2\xa0' \!
>  : "✄" U2704 
> # WHITE SCISSORS

Note that tr does not handle multi-character sequences.  If you pass
something like

tr abc xyz

It does *not* look for "abc" sequences and convert only those sequences.
Rather, it looks at single characters.  It converts 'a' to 'x', and 'b'
to 'y', and 'c' to 'z'.

The number of characters in the first pattern is supposed to match the
number of characters in the second pattern, so that there is a 1:1
mapping.

GNU tr also does not handle multi-byte *characters* correctly (which
violates POSIX -- it's a known bug).

So, your tr command actually converts all c2 bytes into ! and all a0
bytes into ! as well.  Not *just* c2a0 pairs.

Nevertheless, this is useful as a first pass approximation to say that,
hey, there *might* be a bunch of NBSPs here, and you should take a
closer look.

NBSPs most often result when someone gets lazy and pastes a line from
a web page or from a Microsoft Word/Excel document into a Unix
terminal or X11 application, instead of pasting just the characters
they actually want.  Web pages, especially *older* web pages, often
use NBSPs for primitive formatting.



Re: Using .XCompose

2020-07-13 Thread Greg Wooledge
On Sun, Jul 12, 2020 at 02:51:33PM +, Ajith R wrote:
> 5) execute grep $'\x00A0' .XCompose. All lines from the .XCompose file were 
> listed.

Bash's $'...' quoting allows several different forms, and you've used
the wrong one.  The \x is followed by *two* hex digits, to give a single
byte.  You've got $'\x00' which is a NUL byte.  Passing a NUL byte as
an argument to a command is equivalent to passing the empty string.

So, basically you have run

grep '' .XCompose

which, as you observed, gives you every line of the file.

I would imagine you were trying to pass a Unicode character.  If that's
the case, you need the \u or \U form instead.

grep $'\u00A0' .XCompose

Unicode character 00A0 is a non-breaking space.  It's not clear whether
that was your intention or not.

> I noticed that there is $ sign before the search string, which I couldn't 
> understand. I removed it and re-executed the new grep command grep '\x00A0' 
> .XCompose. Now it doesn't return the line

Uh... you mean you *weren't* trying to grep for non-breaking spaces
in your file using bash's $'...' quoting syntax?  You're just typing
something you found at random on the Internet without understanding
it?  That's pretty dangerous.

 might be good reading for you at
this point.

> 6) The command grep "W" .XCompose | tr $'\xc2\xa0' \! returns 
> grep "W" .XCompose | tr $'\xc2\xa0' \!

The two hex bytes c2 a0 are the UTF-8 encoding of a non-breaking space,
so it *does* seem like you're chasing after non-breaking spaces for
some reason

If that's truly your goal, you might also want to pursue configuring
your text editor to show them to you.  There are various ways to do
that, depending on which text editor you use.

(I don't even know whether you're in a UTF-8 encoding, though, so
who knows whether those are even the correct bytes for an NBSP in
your locale.  You're better off using \u00A0 instead.)



Re: Using .XCompose

2020-07-12 Thread David Wright
I have cat /etc/default/keyboard

XKBMODEL="pc105"
XKBLAYOUT="us"
XKBVARIANT=""
XKBOPTIONS="lv3:ralt_switch,compose:caps,terminate:ctrl_alt_bksp"
BACKSPACE="guess"

On Sun 12 Jul 2020 at 14:51:33 (+), Ajith R wrote:

> Using Konsole from my home directory
> 
> 1)executed setxkbmap -layout us
> 2)executed xmodmap which gave the following output
> 
> xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):
> 
> shift       Shift_L (0x32),  Shift_R (0x3e)
> lock        Caps_Lock (0x42)
> control     Control_L (0x25),  Control_R (0x69)
> mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
> mod2        Num_Lock (0x4d)
> mod3      
> mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
> mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

As expected from /e/d/k at the top, mine has slight differences:

xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift   Shift_L (0x32),  Shift_R (0x3e)
lock  
control Control_L (0x25),  Control_R (0x69)
mod1Alt_L (0x40),  Meta_L (0xcd)
mod2Num_Lock (0x4d)
mod3  
mod4Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

but note that all my whitespace is spaces, whereas yours has a
0xc2 0xa0 sequence preceding each space.

> 3)executed xmodmap -pk > xmm
> 
> The file named xmm is attached

Again, very similar to mine. The only different lines are:

- 22 0xff08 (BackSpace) 0xff08 (BackSpace) 0xff08 (BackSpace) 0xff08 
(BackSpace) 0x (NoSymbol) 0x (NoSymbol) 0xfed5 (Terminate_Server)
+ 22 0xff08 (BackSpace) 0xff08 (BackSpace) 0xff08 (BackSpace) 0xff08 (BackSpace)

- 66 0xff20 (Multi_key) 0xff20 (Multi_key) 0xff20 (Multi_key) 0xff20 (Multi_key)
+ 66 0xffe5 (Caps_Lock) 0x (NoSymbol) 0xffe5 (Caps_Lock)

- 108 0xfe03 (ISO_Level3_Shift) 0x (NoSymbol) 0xfe03 (ISO_Level3_Shift)
+ 108 0xffea (Alt_R) 0xffe8 (Meta_R) 0xffea (Alt_R) 0xffe8 (Meta_R)

My (-) lines show the results of the three XKBOPTIONS in /e/d/k.
(I have compressed the whitespace here.)

Note that the whitespace in your *attached* file (mixed tabs and
saces) matched my own, whereas the file here in your post does not.
That suggests that the 0xc2 0xa0 sequences may be a result of your
copy/paste operation.

> 4) executed setxkbmap -print which gave the following 
> 
> xkb_keymap {
>         xkb_keycodes  { include "evdev+aliases(qwerty)" };
>         xkb_types     { include "complete"      };
>         xkb_compat    { include "complete"      };
>         xkb_symbols   { include "pc+us+inet(evdev)"     };
>         xkb_geometry  { include "pc(pc104)"     };
> };

xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include 
"pc+us+inet(evdev)+level3(ralt_switch)+compose(caps)+terminate(ctrl_alt_bksp)"  
};
xkb_geometry  { include "pc(pc105)" };
};

again just reflects the additions in my /e/d/k.

> 5) execute grep $'\x00A0' .XCompose.

That's not going to work, on two counts. Firstly, $'\x00' is NUL,
which terminates the string, so grep $'\x00efghijkl' will give
the same result as grep $'\x00'. Secondly, \x should be followed
by only two characters, so grep $'\xc2\xa0' will reveal those
lines with odd whitescape. However, grep $'\xa0' will find them too.

BTW, C2A0 is UTF-8 for the Unicode codepoint \xa0, the unbreakable space.
So if you want to show the contents of a file, it might be better to
do it by incluing the file with your email editor. The output of
commands can be inserted by redirecting the output to a temporary
file and the included likewise.

> I noticed that there is $ sign before the search string, which I couldn't 
> understand. I removed it and re-executed the new grep command grep '\x00A0' 
> .XCompose. Now it doesn't return the line

… because it doesn't contain any lines with \x00A0 in them.

$ man bash

[ snip to line 516 ]

  Words of the form $'string' are treated specially. The word expands
  to string, with backslash-escaped characters replaced as specified
  by the ANSI C standard. Backslash escape sequences, if present, are
  decoded as follows:
  […]
  \xHH   the eight-bit character whose value is the hexadecimal value
 HH (one or two hex digits)
  \u the Unicode (ISO/IEC 10646) character whose value is the
 hexadecimal value  (one to four hex digits)

So you were mixing up those two constructions, perhaps.

> Is it safe to say that the .XCompose file doesn't have the nonbreaking spaces?

If you haven't got it, install the package bsdmainutils which contains
the hexdump command. hexdump -C filename   will reveal exactly what's
in a file, hex to the left, and corresponding characters to the right.
(I alias "hex" to hexdump -C.)

> BTW, I understand that OP refers to me; but, what exactly does it stand for? 
> Original Petitioner?

Or

Re: Using .XCompose

2020-07-12 Thread Ajith R
Hi All,

I will start with what I did in sequence

Using Konsole from my home directory

1)executed setxkbmap -layout us
2)executed xmodmap which gave the following output

xmodmap:  up to 4 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

3)executed xmodmap -pk > xmm

The file named xmm is attached

4) executed setxkbmap -print which gave the following 

xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us+inet(evdev)"     };
        xkb_geometry  { include "pc(pc104)"     };
};

5) execute grep $'\x00A0' .XCompose. All lines from the .XCompose file were 
listed.
So, I replaced the .XCompose file and retyped the three lines (with only space 
typed using the space bar of the kyboardbetween the letters) and executed the 
grep command. Again it returned all lines. So, I replaced .XCompose file with 
just the W line. Again that line was reported by grep. So, I abandoned Kate and 
built one using cat > .XCompose followed by the line  : "This replaces W", 
followed by Enter and Ctrl+D. The grep command returned the line.

I noticed that there is $ sign before the search string, which I couldn't 
understand. I removed it and re-executed the new grep command grep '\x00A0' 
.XCompose. Now it doesn't return the line

6) The command grep "W" .XCompose | tr $'\xc2\xa0' \! returns 
grep "W" .XCompose | tr $'\xc2\xa0' \!

7) I typed W (holding down shift and pressing w). The Konsole (the instance 
from which I issued the command as well as a new instance) did nothing except 
displaying the W. I typed W in Kate with the same result.


Is it safe to say that the .XCompose file doesn't have the nonbreaking spaces?


> You can print all lines of sometextfile which contain them by doing
> this:

> $ grep $'\xc2\xa0' sometextfile

Is the $ just before the search string in single quotes in the grep command 
intentional? If so, what is its significance?


> '!' marks the spot of nonbreaking spaces that made it into OP's first
> report of odd behavior, upon testing the white scissors XCompose rule:

Could you please see if any of the lines in this message too behaves similarly? 
If so, isn't possible that the mail system adds them? 
BTW, I understand that OP refers to me; but, what exactly does it stand for? 
Original Petitioner?

> So those examples, fi and ½, illustrate the difference between
> modification on output and input in English. I can't judge how the OP
> views this, nor whether they are contravening some conventions in
> their own computer culture by trying to make their changes. This
> doesn't even address how a computer responds to a command line
> written in non-latin script.

I am concerned with the internal representation only. That is, I want  
to be replaced with  < U0D4D> . The display of this sequence as a 
ligated conjunct or as three different symbols is dependant on the font the 
user has. Whether this sequence is displayed as the ligated conjunct or as 
three different charcters, it would be read the same. So, there isn't breaking 
of any langauge semantics  or conventions. All this would bring is some ease of 
typing a commonly used conjunct.

> I know knothing about DE menus.
> It would appear from others' posts that DEs can change anything
> and everything.

What does DE stand for?

> May I ask how you happened to find the post about providing linux
> support for the Breton keyboard
> https://dominiko.livejournal.com/20206.html

I found it by searching the net

> Try again, for firefox-esr (and with a ~/.XCompose file that is not
> befouled with nonbreaking spaces).

> But make one change to the procedure. When you launch firefox-esr, do
> so like this:

> $ env GTK_IM_MODULE=xim firefox-esr
> Let us know how that goes.

Yet to do this. Will inform


Thanks everyone for all your help,
ajith

xmm
Description: Binary data


Re: Using .XCompose

2020-07-11 Thread davidson

On Sat, 11 Jul 2020 David Wright wrote:

I would attempt to back out of the changes made. Removing/hiding
.XCompose is an obvious first step.


Yes.

'!' marks the spot of nonbreaking spaces that made it into OP's first
report of odd behavior, upon testing the white scissors XCompose rule:

  $ grep "WHITE SCISSORS"  d-u_xcompose_2020-07-08.nbsp | tr $'\xc2\xa0' \!
 : "✄" U2704 # 
WHITE SCISSORS

This message:

 
https://lists.debian.org/msgid-search/620563117.3978825.1594226239...@mail.yahoo.com
  "Now, things are even more strange. When I press the Caps Lock, a
  strange character appears. [...]"

--
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important

   --Dwight David Eisenhower

Re: Using .XCompose

2020-07-11 Thread davidson

On Sat, 11 Jul 2020 davidson wrote:

On Fri, 10 Jul 2020 Ajith R wrote:


[snip]


So, as Zeenan says, there is something fundamentally wrong in my
system. I have to find that and correct it or reinstall everything.


Is the situation still as you describe here?

 8 July 2020 Ajith R to debian-user
 
https://lists.debian.org/msgid-search/620563117.3978825.1594226239...@mail.yahoo.com


[snip]


If this is still so, we ought to figure out what's going on. To this
end, I previously asked for the output of

$ xmodmap

and

$ xmodmap -pk


These are, by the way, purely diagnostic command lines. They are
requests to print information only. If you issue them as written
above, they will alter nothing except (possibly) our state of
ignorance.

That is, in my ignorant optimism I imagine their output might help
somebody make informed, helpful suggestions.

While I'm here, I will add to that pair a request for the output from
a third, also purely diagnostic:

 $ setxkbmap -print

--
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important

   --Dwight David Eisenhower



Re: Using .XCompose

2020-07-11 Thread David Wright
On Sat 11 Jul 2020 at 08:39:26 (+), davidson wrote:
> On Fri, 10 Jul 2020 Ajith R wrote:
> > Thanks for your experiment. The fact that it works atleast in some
> > applications gives hope.
> 
> […]
> 
> Curious parties (like myself) wishing to understand the orthographic
> peculiarities at issue here, might find the following section of the
> Wikipedia entry on Malayalam script provides brief, helpful
> background:
> 
>  https://en.wikipedia.org/wiki/Malayalam_script#Ligatures

Naturally, this page concerns itself mainly with how "letters" are
written to compose words on the page. But there's a short section at
the end about how the "letters" are represented in the computer and,
possibly, how they are typed in in order to achieve that internal
representation.

Again, I can only talk about languages I understand. In English,
there's a convention that fi is printed differently from the
letters f and i. Similarly, ffi, fl and ffl. However, this
modification is performed on output, in accordance with the font
being used. "Difficult" is always typed in and stored with the
letters f f i.

OTOH, although in the early days of computing, the lack of different
characters forced people to use 1/2 to represent a half, there's no
doubt that ½ exists as a character which can be input and stored as
just that: ½. My father would think it odd that computer keyboards
(often/usually) don't have that key, because all the typewriters
and adding machines from his era did.

So it's natural that I should wish to define a sequence of keystrokes
that types ½, and that's what I have. It's CapsLock 1 2. It might not
work absolutely everywhere, but typically they're going to be places
I wouldn't want or need to use it. For example, the getty where I log
in (can't), and anywhere where keys aren't reflected, like
passwords/phrases (wouldn't).

So those examples, fi and ½, illustrate the difference between
modification on output and input in English. I can't judge how the OP
views this, nor whether they are contravening some conventions in
their own computer culture by trying to make their changes. This
doesn't even address how a computer responds to a command line
written in non-latin script.

> The "appropriate geminate glyph" refered to in property (2) above is
> illustrated in this table, in the "ligated" row under the column
> headed "ṅṅa".
> 
>  https://en.wikipedia.org/wiki/Malayalam_script#Common_consonant_ligatures
> 
> > I copied your exact sentences to my compose file. 
> > 
> > In Konsole the command cat ~/.XCompose gives the result:
> > 
> > include "%L" 
> >   : "ങ്ങ" # Ajith's auto-geminate rule, (U0D19) => (U0D19) (U0D4D) 
> > (U0D19)
> >: "✄"  # (U2704) white scissors, h/t David Wright
> >                 : "ARGA WARGA IN THE DARGA instead of Z"
> 
> Do you know what I see in four lines above, representing the content
> of your ~/.XCompose file?  I see "non-breaking space" characters
> (two-byte sequences 0xc2a0). I see 8 of them in the last line alone
> (the  rule). Do you know what non-breaking space characters are?
> 
> I'm not quite sure how best to describe them, myself.

In TeX, you would type in Mr~Wright, because it's considered that Mr
Wright is not the polite way to print a name in a book. I've never
tested whether modern versions of text will handle Mr Wright directly
as input, because using ~ explicitly has the advantage of making the
modification more apparent. Otherwise, they're indistinguishable from
spaces in text and on the command line, only showing in emacs, where
they're coloured like all "idiosyncratic" whitespace.

> But I will tell you what they *aren't*. They aren't spaces. They
> aren't tabs. And the only thing their presence is going to do --in
> your code and in your configuration files-- is wreak havoc.

Similarly, a search like   /Mr Wright   will no longer work in less;
you might have to search   /Mr.Wright   instead, with a wildcard.

> Their name is very ironic. For our purposes,
> 
>   1. they aren't spaces, and
>   2. they break EVERYTHING.
> 
> Whatever it is you are doing that puts them there, STOP DOING IT.
> 
> […]
> 
> > So, as Zeenan says, there is something fundamentally wrong in my
> > system. I have to find that and correct it or reinstall everything.

I would attempt to back out of the changes made. Removing/hiding
.XCompose is an obvious first step. The keymap changes might be
trickier: are there changes in /usr/share/X11/kbd/ or have they
only added files in /etc/X11/kbd/? I know knothing about DE menus.
It would appear from others' posts that DEs can change anything
and everything.

> > > firefox-esr issued the following errors, which appear to be explanatory:
> > > (firefox-esr:11619): Gtk-WARNING **: 16:27:05.630: GTK+ supports to 
> > > output one char only:

I've never tried to do anything about special characters with FF.
They either work (like ½) in both the address and search bars, or
I expect google or whatever to sort it out like typos (cf role
and rôle). Bu

Re: Using .XCompose

2020-07-11 Thread davidson

On Sat, 11 Jul 2020 davidson wrote:

On Fri, 10 Jul 2020 Ajith R wrote:

Hi,

Thanks for your experiment. The fact that it works atleast in some
applications gives hope.


There remains the strange fact that in no application (yet) have we
seen *both* properties:

1. application produces multiple characters in accordance with
   XCompose rule that specifies this

2. application displays the sequence of the three unicode characters
   U+0D19 U+0D4D U+0D19 as the appropriate geminate glyph

[snip]


The "appropriate geminate glyph" refered to in property (2) above is
illustrated in this table,


[WHEN *cough* ...viewed with an application possessing property (2)]


in the "ligated" row under the column headed "ṅṅa".

https://en.wikipedia.org/wiki/Malayalam_script#Common_consonant_ligatures

Re: Using .XCompose

2020-07-11 Thread davidson

On Fri, 10 Jul 2020 Ajith R wrote:

Hi,

Thanks for your experiment. The fact that it works atleast in some
applications gives hope.


There remains the strange fact that in no application (yet) have we
seen *both* properties:

 1. application produces multiple characters in accordance with
XCompose rule that specifies this

 2. application displays the sequence of the three unicode characters
U+0D19 U+0D4D U+0D19 as the appropriate geminate glyph

I found xterm and mlterm to have property (1), and some graphical
browsers (firefox-esr and qutebrowser) to have property (2). We have
not yet seen anything do both.

(Actually, I have just learned how to make firefox-esr do both. See
GTK_IM_MODULE below.)

Curious parties (like myself) wishing to understand the orthographic
peculiarities at issue here, might find the following section of the
Wikipedia entry on Malayalam script provides brief, helpful
background:

 https://en.wikipedia.org/wiki/Malayalam_script#Ligatures

The "appropriate geminate glyph" refered to in property (2) above is
illustrated in this table, in the "ligated" row under the column
headed "ṅṅa".

 https://en.wikipedia.org/wiki/Malayalam_script#Common_consonant_ligatures


I copied your exact sentences to my compose file. 

In Konsole the command cat ~/.XCompose gives the result:

include "%L" 
  : "ങ്ങ" # Ajith's auto-geminate rule, (U0D19) => (U0D19) (U0D4D) 
(U0D19)
   : "✄"  # (U2704) white scissors, h/t David Wright
                : "ARGA WARGA IN THE DARGA instead of Z"


Do you know what I see in four lines above, representing the content
of your ~/.XCompose file?  I see "non-breaking space" characters
(two-byte sequences 0xc2a0). I see 8 of them in the last line alone
(the  rule). Do you know what non-breaking space characters are?

I'm not quite sure how best to describe them, myself.

But I will tell you what they *aren't*. They aren't spaces. They
aren't tabs. And the only thing their presence is going to do --in
your code and in your configuration files-- is wreak havoc.

Their name is very ironic. For our purposes,

  1. they aren't spaces, and
  2. they break EVERYTHING.

Whatever it is you are doing that puts them there, STOP DOING IT.

You can print all lines of sometextfile which contain them by doing
this:

 $ grep $'\xc2\xa0' sometextfile


Next, I issued setxkbmap -layout us, just to make sure that the layout is us.

I used konsole and UXterm to test Z. The test failed with Z remaining 
unchanged. 


The non-breaking spaces alone explain this much.


So, as Zeenan says, there is something fundamentally wrong in my
system. I have to find that and correct it or reinstall everything.


Is the situation still as you describe here?

  8 July 2020 Ajith R to debian-user
  
https://lists.debian.org/msgid-search/620563117.3978825.1594226239...@mail.yahoo.com

  Now, things are even more strange. When I press the Caps Lock, a
  strange character appears. (I copy pasted it, searched the net and
  found it to be unicode compose character.) Then when I type s, the
  Caps Lock light gets switched on and the character S (caps) appears
  on screen. Then when I type X, the compose character and S become
  invisible and x/X doesn't appear. When I change focus to another
  window, the terminal in which I was typing shows the compose
  character and S.

  This behaviour has not changed after I unchecked the settings
  through KDE settings menu, after restarting computer, re-issuing
  xmodmap command or changing the layout to us. The same sequence is
  seen with typing in Kate as well. Even when I use Scroll Lock as the
  compose key, the situation is only different in that the s is not
  capitalised.

If this is still so, we ought to figure out what's going on. To this
end, I previously asked for the output of

 $ xmodmap

and

 $ xmodmap -pk


I tried in another computer with Debian and KDE. The Z gets replaced
by the first letter in replacement string, while nothing happens in
Xterm.


Try again, for firefox-esr (and with a ~/.XCompose file that is not
befouled with nonbreaking spaces).

But make one change to the procedure. When you launch firefox-esr, do
so like this:

 $ env GTK_IM_MODULE=xim firefox-esr

Let us know how that goes.


Is KDE the problem? I checked IceWM and got the same result.


into what appears (to my utterly ignorant eye) to be a "freshly
synthetic" glyph


That "freshly synthetic" glyph would be the geminate form.


I must say that the more I learn about the project you outlined in
your original post, the more interesting it becomes.

May I ask how you happened to find the post about providing linux
support for the Breton keyboard

  https://dominiko.livejournal.com/20206.html

which you mentioned in this 7 July reply to David Wright?

  
https://lists.debian.org/msgid-search/563409927.3312315.1594115078...@mail.yahoo.com

However it is that you came across it, that is a very interesting case
as well.


firefox-esr issued the following errors, which appea

Re: Using .XCompose

2020-07-10 Thread davidson

On Thu, 9 Jul 2020 davidson wrote:

I have conducted an experiment with the following ~/.XCompose file,
and tried to document it relatively thoroughly below.

[snip]


%% THREE XCOMPOSE RULES to test

$ cat ~/.XCompose
include "%L"
   : "ങ്ങ" # Ajith's auto-geminate rule, (U0D19) => (U0D19) (U0D4D) 
(U0D19)

   : "✄"  # (U2704) white scissors, h/t David Wright
 : "ARGA WARGA IN THE DARGA instead of Z"


[snip]

There is a mistake here. A missing step.


%% ARGA WARGA

The third rule ('Z' => "ARGA WARGA...Z") was easiest to test:

1. Open the application. (If necessary, navigate to a text entry field.)


STEP 1-AND-A-HALF. Hold down the Shift key.


2. (While under "us" keyboard layout) strike the key labeled "Z" on my
   standard US laptop keyboard
3. Observe whether

 ARGA WARGA IN THE DARGA instead of Z

   is printed.

The two terminal emulators passed this test. The graphical web browsers 
failed

in an interesting way. Instead of displaying

ARGA WARGA IN THE DARGA instead of Z

in the text entry field, they displayed just

A


--
You won't feel the collar if you don't go anywhere.

Re: Using .XCompose

2020-07-09 Thread davidson

On Wed, 8 Jul 2020 Ajith R wrote:

Hi Zenaan,

> Under the "Layout" tab, I have the option for "Compose key" - this
> is a drop down list, and I chose the "Scroll Lock" key as my
> compose key. 


Similar options are there for KDE too. I tried setting the Compose
key from the KDE settings menu after trying

  xmodmap -e "keysym Caps_Lock = Multi_key"

suggested by Greg. My .XCompose file is:

include "%L"
   : "✄"   U2704 # WHITE SCISSORS

Now, things are even more strange. When I press the Caps Lock, a
strange character appears. (I copy pasted it, searched the net and
found it to be unicode compose character.)


Incidentally, I have sometimes found that attempting to copy-paste
strange characters can result in even *stranger* characters. (This has
the potential to lead to more confusion, instead of less.)

Since the character of interest is one you are typing yourself, you
might try this:

 $ xxd - # and then type whatever you want to examine

When you're done entering what you want to examine, type Ctrl-d. Type
it once if you're at the beginning of a new line. Type it twice if you
aren't. (Somebody smart might explain to us why this is so.)

If you don't have xxd installed, you could use the following line as a
poor man's xxd:

 $ od -Ax -tx1z -v - # type whatever, do Ctrl-d to end it, as above

the "od" program is in coreutils, which "apt-cache show coreutils"
says is an "Essential: yes" package. So you probably have it for sure.

Replace the last "-" with "> somefilename" (in either command above)
if you want to put the output into a file to show somebody else, or to
treasure it always as a keepsake. But make sure that "somefilename"
isn't already a file containing stuff you want to keep (because you
will lose that stuff forever, instantly).


Then when I type s, the Caps Lock light gets switched on and the
character S (caps) appears on screen. Then when I type X, the
compose character and S become invisible and x/X doesn't
appear. When I change focus to another window, the terminal in which
I was typing shows the compose character and S.


IT'S ALIVE!

Sorry, this is probably a very frustrating development. (I'm sure I'd
be pretty upset in your shoes.)

I wonder if the output from either

 $ xmodmap # with no arguments, just the bare command

or

 $ xmodmap -pk

would be illuminating.

The output from the first command (the bare command with no arguments)
will probably not be too overwhelming. It ought to summarise your
current modifier keys.

The output from the second is your keymap table, and will likely be of
considerable size. If you want to review it in the moment, I would
suggest doing

 $ xmodmap -pk | less -S

so you can examine it in a pager. The "-S" option keeps the pager from
wrapping long lines, and there could be some pretty long lines when
you print your current keymap table. This way you can get some
semblance of columns, and use the arrow keys to scroll left/right to
view those long lines, instead of having trying to disentangle a bunch
of wraparound garbage.

If you want to share the output with us here (and I hope that you do),
you can put the output into a pair of files like so:

 $ xmodmap > somefilename.pm
 $ xmodmap -pk > somefilename.pk

And then import them into a message body, however one does that in
your email setup.

As always, these commands all have manual pages, and you have these
pages installed if you have the commands. You can read them over if
you are at all curious, at least to reassure yourself that I'm not
telling you to do something evil that you don't want done.

 $ man command # read the command manual in a pager
 $ man -f command # see super-brief description of command
 $ man -k commandliketerm # search for pertinent commands

But you came here with a manual page referenced in your original post
at the top of this thread, didn't you? So you don't need me telling
you this.


this behaviour has not changed after I unchecked the settings
through KDE settings menu, after restarting computer, re-issuing
xmodmap command or changing the layout to us. The same sequence is
seen with typing in Kate as well. Even when I use Scroll Lock as the
compose key, the situation is only different in that the s is not
capitalised.

Any idea what might be wrong?


Well, I can't really say. I haven't quite followed the progression
here as closely as I would have liked to.

And I don't have a whole lot of experience with many of the tools that
you've been playing with. This is all a learning experience for me,
too.

But I am looking forward to seeing what we can sort out once we see
your modifier table and keymap table.

I hope your week has gone well, all things considered.

--
You won't feel the collar if you don't go anywhere.

Re: Using .XCompose [resend of xev_output_annotated.txt]

2020-07-09 Thread davidson

On Thu, 9 Jul 2020 davidson wrote:
[snip]


Finally, in case it is of interest to anyone, in the attached file
"xev_output_annotated.txt" is some xev(1) output with commentary
that gives a detailed close-up of performing steps 4 through 6 in an
xterm. (As with the system synopsis, if it happens to "get lost"
I'll just post it the message body of a follow-up.)


It appears that the process of attaching that file to my previous
message caused alteration of those bytes encoding the malayalam
characters. This affected all lines beginning with either

 XLookupString gives N bytes:

or

 XmbLookupString gives N bytes:

for N greater than 0.

The remainder of this message is (hopefully) a more faithful
representation of the file (previously attached as
"xev_output_annotated.txt").



$ man xev
[...]
DESCRIPTION

  Xev creates a window and then asks the X server to send it events
  whenever anything happens to the window (such as it being moved,
  resized, typed in, clicked in, etc.).  You can also attach it to an
  existing window.  It is useful for seeing what causes events to
  occur and to display the information that they contain; it is
  essentially a debugging and development tool, and should not be
  needed in normal usage.

This is the command I issued from within an xterm (uxterm, really) to
launch xev and attach it to that terminal's window.

$ xev -id $WINDOWID -event keyboard # I press enter, of course

# And here is the release of the enter key:

KeyRelease event, serial 18, synthetic NO, window 0x6f,
root 0x102, subw 0x0, time 76502401, (1362,764), root:(1364,766),
state 0x0, keycode 36 (keysym 0xff0d, Return), same_screen YES,
XLookupString gives 1 bytes: (0d) ""
XFilterEvent returns: False

# Next, I strike the capslock key to enter the Malayalam keymap, "ml".
# The capslock key's keycode happens to be 66. This is a relatively
# low-level identifier, mechanical, relatively meaningless in itself,
# fixed by factual accident.
#
# Its keysym, under my configuration, is apparently .
#
# A keysym is an identifier of somewhat higher abstraction than a
# keycode, and is meant to *mean* something. (I mean, just compare the
# two names to see this!)
#
# The following *three* records correspond to striking this key.
#
# NB: For some reason, each key struck seems to correspond to *three*
# records in the xev output:
#
# 1. a KeyRelease event (kind of weird, but that's how it is).
# 2. a KeyPress event.
# 3. a KeyRelease event.

KeyRelease event, serial 21, synthetic NO, window 0x6f,
root 0x102, subw 0x0, time 76506392, (1362,764), root:(1364,766),
state 0x0, keycode 66 (keysym 0xfe08, ISO_Next_Group), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 21, synthetic NO, window 0x6f,
root 0x102, subw 0x0, time 76506392, (1362,764), root:(1364,766),
state 0x0, keycode 66 (keysym 0xfe08, ISO_Next_Group), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 21, synthetic NO, window 0x6f,
root 0x102, subw 0x0, time 76506480, (1362,764), root:(1364,766),
state 0x2000, keycode 66 (keysym 0xfe08, ISO_Next_Group), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

# Next, I hold down a shift key (left shift, as it happens).
#
# NB: The following *two* records correspond to this. First a
# KeyRelease, then a KeyPress.

KeyRelease event, serial 21, synthetic NO, window 0x6f,
root 0x102, subw 0x0, time 76509510, (1362,764), root:(1364,766),
state 0x2000, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 21, synthetic NO, window 0x6f,
root 0x102, subw 0x0, time 76509510, (1362,764), root:(1364,766),
state 0x2000, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

# Then, still holding down the shift key, I strike the key labeled "U"
# on my standard US laptop keyboard.
#
# NB: The next *four* records correspond to this action.
#
#   * The first two events are due to holding down the key labeled
# "U" (KeyRelease event followed by KeyPress),
#
#   * followed by a third, MAGICALLY INTERPOLATED, KeyPress event
# (presumably due to the relevant entry in ~/.XCompose),
#
#   * and wrapped up with the KeyRelease event corresponding to
# releasing that "U" labeled key.

KeyRelease event, serial 21, synthetic NO, window 0x6f,
root 0x102, subw 0x0, time 76509907, (1362,764), root:(1364,766),
state 0x2001, keycode 30 (keysym 0x1000d19, U0D19), same_screen YES,
XLookupString gives 3 bytes: (e0 b4 99) "ങ"
XFilterEvent returns: False

KeyPress event, s

Re: Using .XCompose

2020-07-09 Thread The Wanderer
On 2020-07-09 at 20:38, Zenaan Harkness wrote:

> `apt-get` seems to have a `reinstall` subcommand, but I could not
> find the same in the `apt` manpage for some reason.

It's there, in the fourth subheading under DESCRIPTION:

>>install, reinstall, remove, purge (apt-get(8))
>>Performs the requested action on one or more packages specified 
>> via
>>regex(7), glob(7) or exact match. The requested action can be
>>overridden for specific packages by appending a plus (+) to the
>>package name to install this package or a minus (-) to remove it.

Plus a couple more paragraphs. Basically the same behavior as the
apt-get version, and they even point you to apt-get(8) for more.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Re: Using .XCompose

2020-07-09 Thread Zenaan Harkness
On Thu, Jul 09, 2020 at 07:10:42PM +, Ajith R wrote:
> 
> > It sounds like something is fundamentally wrong with your keymap.
> 
> I started first by making a new layout file 'mal' and loading it using 
> setkbmap. Once I was sure the layout was working ok, I copied the layout to 
> the symbol file 'in'. Now, to check for the .XCompose, I load the us layout 
> (which I haven't modified). I have changed the keyboard file as well ( using 
> dpkg-reconfigure keyboard-configuration   )
>  
> 
> > I suggest starting again, resetting everything back to your chosen defaults 
> > at install - reset your modified keymap file back to whatever you copied to 
> > begin the exercise, and test
> > that compose is working as it should.
> 
> I have reset everything back to the original as far as I can recollect, but 
> COmpose is not working. Is there a way to reset the system other than by 
> reinstalling?


I don't know sorry.  But it sounds like you've made an important discovery that 
something is not quite right about your current /etc or etc.

To reset without reinstalling, others will probably need to jump in and assist 
with specifics, but the gist of it is this:

Work out which package contains the file you've modified, make a backup of the 
file you've modified, reinstall the package.

`apt-get` seems to have a `reinstall` subcommand, but I could not find the same 
in the `apt` manpage for some reason.

Good luck,



Re: Using .XCompose

2020-07-09 Thread davidson

I have conducted an experiment with the following ~/.XCompose file,
and tried to document it relatively thoroughly below.

It is my hope that OP and/or others may find some of this
(unfortunately rather voluminous) information helpful or at least
somewhat interesting, though it is difficult for me to know precisely
whether or how they will be able to use it.

Of course, to interpret any meaning from the results presented here,
the context/environment in which the test was conducted matters
greatly. Details about my system are attached, in the file
"system_synposis_bbhuit.txt". (In case that attachment gets lost
somehow, I will simply post the same information in a follow-up
message.)


%% THREE XCOMPOSE RULES to test

$ cat ~/.XCompose
include "%L"
   : "ങ്ങ" # Ajith's auto-geminate rule, (U0D19) => (U0D19) (U0D4D) 
(U0D19)
   : "✄"  # (U2704) white scissors, h/t David Wright
 : "ARGA WARGA IN THE DARGA instead of Z"

I started an X Window session, and then in a few applications I tested
whether the three custom rules above were effective.

For the tests, I used a couple of terminal emulators for X (xterm and
mlterm) and a couple of graphical web browsers (firefox-esr and
qutebrowser):

davidson@bbhuit:0 ~$ dpkg-query -l --no-pager xterm mlterm firefox-esr qutebrowser 
Desired=Unknown/Install/Remove/Purge/Hold

| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---
ii  firefox-esr68.10.0esr-1~deb10u1 amd64Mozilla Firefox web 
browser - Extended Support Release (ESR)
ii  mlterm 3.8.6-2  amd64MultiLingual TERMinal
ii  qutebrowser1.6.1-2  all  Keyboard-driven, vim-like 
browser based on PyQt5
ii  xterm  344-1amd64X terminal emulator


%% ARGA WARGA

The third rule ('Z' => "ARGA WARGA...Z") was easiest to test:

 1. Open the application. (If necessary, navigate to a text entry field.)
 2. (While under "us" keyboard layout) strike the key labeled "Z" on my
standard US laptop keyboard
 3. Observe whether

  ARGA WARGA IN THE DARGA instead of Z

is printed.

The two terminal emulators passed this test. The graphical web browsers failed
in an interesting way. Instead of displaying

 ARGA WARGA IN THE DARGA instead of Z

in the text entry field, they displayed just

 A

Also, upon starting up (but only on the first start-up since
installation of the three rules in ~/.XCompose) , firefox-esr issued
the following errors, which appear to be explanatory:

 (firefox-esr:11619): Gtk-WARNING **: 16:27:05.630: GTK+ supports to output one 
char only:
 "ങ്ങ" # Ajith's auto-geminate rule, (U0D19) => (U0D19) (U0D4D) (U0D19):
: "ങ്ങ" # Ajith's auto-geminate rule, (U0D19) => (U0D19) (U0D4D) 
(U0D19)

 (firefox-esr:11619): Gtk-WARNING **: 16:27:05.630: GTK+ supports to output one 
char only:
 "ARGA WARGA IN THE DARGA instead of Z":
  : "ARGA WARGA IN THE DARGA instead of Z"

(I have split each error into three separate lines above to improve legibility.)

Although both web browsers performed identically, failing in the same
way, only firefox-esr issued this explanatory error message.

Unlike firefox-esr, qutebrowser does not use libgtk (do "apt-cache
depends qutebrowser" to see its dependencies), but both graphical web
browsers failed this test identically.


%% WHITE SCISSORS

The second rule (David Wright's white scissors rule) was tested as
follows:

 1. Open the application. (If necessary, navigate to a text entry field.)

 2. Under "us" keyboard layout, hold down the compose key. Strike the
key labeled "S" on my standard US laptop keyboard. Release the
compose key. Strike the key labeled "X".

 3. Observe whether

✄

   is printed.

All four applications passed this test. (I should mention that I have
noticed that sometimes when I use the compose key, it seems to get
ignored on the first try. It happens frequently enough that it has
become second nature to me to simply backspace and try again, when
this happens. Whether this is human error, or something else, is not
something I have spent time investigating. Whatever the cause, it does
not trouble me more than other commonly self-inflicted typos do.)

NB: If, like me, you occasionally confuse the Ctrl key with the
compose key, then keep in mind that when testing this rule in a
terminal emulator, that typing Ctrl-s (presumably by accident) may
well stop the terminal from echoing entered characters to the display
until you enter Ctrl-q to resume normal terminal operation. (That is
to say, Ctrl-s doesn't "break your keyboard", it only pauses your
terminal's printout to the display until you resume it with Ctrl-q.)


%% AUTO-GEMINATION

Finally. The first 

Re: Using .XCompose

2020-07-08 Thread Zenaan Harkness
On Wed, Jul 08, 2020 at 07:14:33PM -0500, David Wright wrote:

> > I was just trying to find out the reason why the 'composting' was
> > not working. I tried including the modifier name and also without
> > it. I tried moving the key to the first layer of keyboard layout
> > (without shift or other modifiers). Even that was not working.
> 
> I think you're now talking about the /usr/share/X11/xkb/ files,
> and overriding them in /etc/. I don't touch those, and can't help you
> there. I read them, to help in configuring /etc/default/ files, but
> no more than that.

I added a new "FunkyZen" layout file to /usr/share/X11/xkb/, a modification of 
the US keymap I think.

Can we create new layouts by just adding a file to /etc ??


> I should have said that the usual way to write this file is to run
> # dpkg-reconfigure keyboard-configuration
> (and that command can also be run after editing it in order to
> validate/correct it). I should also add that in my experience,
> it's best done in a VC, without an X session even running.

Ooh!  Now _that_ could be highly useful next time he (this friend of mine who 
seems to be oddly wearing a brown paper bag right now) looks at my, I mean his 
custom keyboard layout...


> (In systemd, there's also this mysterious command
> # service keyboard-setup restart
> about which I know nothing. I've never used it.)

Must investigate.

If my friend were to write an ad hock end user custom keyboard layout 
customizer, what would be the minimal set of perms required to do its job?  (My 
friend does not use `sudo` you see...)

> > and my .XCompose file now is 
> > include "%L" 
> >    : "✄"   U2704 # WHITE SCISSORS
> > 
> > However, when I press Caps Lock followed by s and then x or if I
> > keep the Caps Lock pressed while I press s and x in sequence, I
> > don't get scissors. I get S and X.
> 
> That appears to indicate that CapsLock is not your Compose Key, but is
> behaving as normal, turning s and x into S and X.

Although various desktops have GUIs to choose Compose key, it is Better ™©® to 
set this at a lower level so it also kinda works in the Linux console.  I guess 
my friend's question is how best to arrange the perms/sudo side of things for a 
GUI that wants to make this easy for end users?



Re: Using .XCompose

2020-07-08 Thread Zenaan Harkness
On Wed, Jul 08, 2020 at 04:37:19PM +, Ajith R wrote:
> Hi Zenaan,
> 
> > Under the "Layout" tab, I have the option for "Compose key" - this is a 
> > drop down list, and I chose the "Scroll Lock" key as my compose key.
> 
> 
> Similar options are there for KDE too. I tried setting the Compose key from 
> the KDE settings menu after trying xmodmap -e "keysym Caps_Lock = Multi_key" 
> suggested by Greg. My .XCompose file is:
> include "%L"
>    : "✄"   U2704 # WHITE SCISSORS
> 
> Now, things are even more strange. When I press the Caps Lock, a strange 
> character appears. (I copy pasted it, searched the net and found it to be 
> unicode compose character.) Then when I type s, the Caps Lock light gets 
> switched on and the character S (caps) appears on screen. Then when I type X, 
> the compose character and S become invisible and x/X doesn't appear. When I 
> change focus to another window, the terminal in which I was typing shows the 
> compose character and S.
> 
> This behaviour has not changed after I unchecked the settings through KDE 
> settings menu, after restarting computer, re-issuing xmodmap command or 
> changing the layout to us. The same sequence is seen with typing in Kate as 
> well. Even when I use Scroll Lock as the compose key, the situation is only 
> different in that the s is not capitalised.
> 
> Any idea what might be wrong?

It sounds like something is fundamentally wrong with your keymap.

I suggest starting again, resetting everything back to your chosen defaults at 
install - reset your modified keymap file back to whatever you copied to begin 
the exercise, and test that compose is working as it should.

Then, make no more than a single change, apply and test that single change.  
Don't move forward till the one change is working.

That's what I did (although it's been a 2 or 3 years since I dabbled) - I had 
one tiny little brace missing at one stage, and when you don't see it, you just 
don't see it, so after that I brutally realigned everything with obnoxious 
spaces, so that all tha braces, and commas, lined up - THAT solved the 
accidental missing brace which never bit me again :/



Re: Using .XCompose

2020-07-08 Thread David Wright
Sorry if the format looks a mess, but it's a consequence of replying to HTML.

On Tue 07 Jul 2020 at 09:44:38 (+), Ajith R wrote:

> I was looking at XCompose(3). Thanks for pointing out the mistake.

It wasn't a mistake on your part. It was pointed out to me that
section 3 has an alias redirecting to the real man page, which is
actually still in the right place, section 5. You just followed that
link. I was worried that you might have been reading a real section 3
man page, most of which are incomprehensible to us mere mortals.

> > As I understand .XCompose, it is designed for "compositing", […]

> I understand that. My letter is in the 'shift' set of
> keystrokes. That was the reason I included it. Moreover, the Compose
> manual page states that 'Each event consists of a specified input
> keysym, and optional modifier states:
> [([!] ([~] MODIFIER)...) | None] ". '

Sure. But typically, for ordinary letter keys, you would expect each
to have its own keysym when shifted. Thus (using English) you see
definitions sequences like

   : "©"   copyright # COPYRIGHT SIGN
   : "©"   copyright # COPYRIGHT SIGN
   : "©"   copyright # COPYRIGHT SIGN
   : "©"   copyright # COPYRIGHT SIGN
   : "©"   copyright # COPYRIGHT SIGN
   : "©"   copyright # COPYRIGHT SIGN

Obviously, I'm struggling when it comes to your own example as I don't
know how these characters relate to one another. So my examples will
be using Latin characters.

It's perfectly possible to write compositions like these:

 : "xx"
 : "XX"

where X is shifted x.

You can even have:

  : "yes"

but the problem is that whenever you type the key y, the system will
wait for another character to be typed. If you want to type the letter
y, you have to type y y Rubout Rubout. For the letter X, you have to
type X Rubout. Not very satisfactory.

What appears on the right is flexible, but the left part, before the
colon, is more constrained. To repeat myself, you should probably look
at the system file for your own locale (and perhaps others) to see
what they use. My own, /usr/share/X11/locale/en_US.UTF-8/Compose, has
the letters (in both cases) and digits (including  as well as <3>,
surprisingly), and punctuation keys by name ( etc). My Compose
key (CapsLock) is .

I also see keys that I have no idea about how to generate them, like
   and most of the
Unicode-defined ones. But noticeable is the fact that the *first* key is
almost always  or . That's because
those few keys become unusable on their own, dead. (There are also 9
oddities that mean nothing to me.)

What I don't see are any modifiers like shift and ctrl. In fact, I
found none in /usr/share/X11/locale/*/Compose on my system. Perhaps
yours do, in which case you can follow their style. I can't help
you there.

> I was just trying to find out the reason why the 'composting' was
> not working. I tried including the modifier name and also without
> it. I tried moving the key to the first layer of keyboard layout
> (without shift or other modifiers). Even that was not working.

I think you're now talking about the /usr/share/X11/xkb/ files,
and overriding them in /etc/. I don't touch those, and can't help you
there. I read them, to help in configuring /etc/default/ files, but
no more than that.

> So, I
> was wondering if there was a syntax error in the way I was
> specifying my requirement. I understand the use of Compose key. But,
> I was not trying the usual 'composting' (by means of a compose
> key). I  want one character to be replaced with its geminate form
> whenever it is typed. If the keyboard layout specification allowed
> more than one character for a keystroke, I wouldn't have needed
> it. Hence the need for Compose mechanism. A similar approach is
> explained here https://dominiko.livejournal.com/20206.html . However
> in it, the author has defined a personal use Unicode character, but
> I use one of the Unicode defined characters.

If you're willing to lose the normal function of the key, then as
shown above, you can turn any keystroke into a string.

> In the symbol file, he had used key
>  { type[group1] = "FOUR_LEVEL_C_HWERTY", [ UF8FD, UF8FE, UF8FF, 
> Greek_alpha ] };
> I didn't understand the use of type[group1 = "..."], but thought
> that it was not essential. Anyway, the layout is working as expected
> in that the characters returned by layout is as defined.

No idea about that stuff.

> The compose mechanism is not working.

Syntax errors are one possibility. I don't know how and when they are
handled. Another is making changes have any effect. (In the past,
I've edited the file in a VC, and started X from another VC after any
changes have been saved.)

A third is that every recipe at the left side must not entirely
include any other. Hence:

: "—"   U201

Re: Using .XCompose

2020-07-08 Thread Ajith R
Hi Zenaan,

> Under the "Layout" tab, I have the option for "Compose key" - this is a drop 
> down list, and I chose the "Scroll Lock" key as my compose key.


Similar options are there for KDE too. I tried setting the Compose key from the 
KDE settings menu after trying xmodmap -e "keysym Caps_Lock = Multi_key" 
suggested by Greg. My .XCompose file is:
include "%L"
   : "✄"   U2704 # WHITE SCISSORS

Now, things are even more strange. When I press the Caps Lock, a strange 
character appears. (I copy pasted it, searched the net and found it to be 
unicode compose character.) Then when I type s, the Caps Lock light gets 
switched on and the character S (caps) appears on screen. Then when I type X, 
the compose character and S become invisible and x/X doesn't appear. When I 
change focus to another window, the terminal in which I was typing shows the 
compose character and S.

This behaviour has not changed after I unchecked the settings through KDE 
settings menu, after restarting computer, re-issuing xmodmap command or 
changing the layout to us. The same sequence is seen with typing in Kate as 
well. Even when I use Scroll Lock as the compose key, the situation is only 
different in that the s is not capitalised.

Any idea what might be wrong?
Thanks,
ajith




Re: Using .XCompose

2020-07-08 Thread Ajith R
Hi Greg,

>
Does your Caps Lock key work for Compose if you set it with:

xmodmap -e "keysym Caps_Lock = Multi_key"
>

I tried this and found that the test definition in .XCopose file is working.
However, when I change the .XCompose definition to  <ങ>              
       : "✄"
or to
 <ങ> <ങ>                      : "✄", it is not working
or to
                   : "ങ്ങ"



>
Also, as mentioned before, please make sure you open a new terminal
(or other X11 application) after modifying your .XCompose file.  That
file is only read when libx11 initializes during the start of a new
client application.
>

Just an observation. When it works, the Compose definition works in the 
terminal from which the command is issued. I did test the definitions that 
don't work in a new terminal and Kate.

Thanks,
ajith



Re: [offlist] Re: Using .XCompose

2020-07-07 Thread davidson

On Wed, 8 Jul 2020 Zenaan Harkness wrote:

On Wed, Jul 08, 2020 at 02:59:20AM +, Ajith R wrote:

Hi David,




As a rule, send replies to the listserv address:

    debian-user@lists.debian.org

2. In-Line replies, instead of Top-Posting
3. I apologise for being a Terrible Person


Hey!  I thought I had a patent, trademark _and_ copyright on self
deprecation ;)


Neuroticism wants to be free.

--
You won't feel the collar if you don't go anywhere.

Re: [not-so-offlist] posting style [was Re: Using .XCompose]

2020-07-07 Thread davidson

On Wed, 8 Jul 2020 Ajith R wrote:



Hi David,




Debian conformant style looks like this instead:




Do I understand the style correctly now?


LOL. Probably not. Maybe I should have allowed your discovery of the
mailing list's quoting conventions to take its natural course.

It was maybe silly of me to explain it, before we've figured out why
some of your seemingly reasonable XCompose lines, like this one

   : "ങ്ങ"  # Ajith's auto-geminate rule

aren't effective.


BTW, a query about how the original message is quoted with '<'.


That left angle bracket '<' points in the wrong direction.

A conventional quoted-line prefix is

  "> "

which is a right angle bracket followed by a space.

A mail client that understands this convention may interpret these
indicators, and display any text so prefixed in some other distinctive
fashion. The prefix is mere markup that means "The following text on
this line is quoted material".

And so what one sees displayed in a mail client may not exactly
correspond to the plain text of the message body. Instead of literal
angle bracket prefixes, you might see some other visual representation
of the embedding.

Examining message bodies in a text editor (or with a pager like
"less") might help reduce confusion.


Is it done by hand or does any email clients do it automatically?


Only the artisanal hand-quoter would be able to tell the difference!

And I'm sure there exists at least one maverick mail client that does
not do so automatically.

But I have not taken a survey of email clients. Mine (alpine) does do
so automatically whenever I include a message body in my reply to that
message. And even if it did not automatically prefix the lines of the
quoted message body, then it would not be difficult to tell any
decently functional text editor to employ

 "> "

as a comment string, and then select and comment blocks of quoted
text.

And these prefixes will stack, over the course of a thread. Naturally
enough, email lends itself to replies. So you have an initial message
(degree zero), replies to such a message (degree one), and replies to
replies (degree two), and so on.

A message of the Nth degree might retain lines of quoted material from
N previous messages. And if it does, then one expects to find each of
those lines constituting the most deeply embedded material prefixed
with N instances of

 "> "


Is it necessary that each line s marked with '<'?


All the cool people prefix each line of a quoted message body with

 "> "

It is cool to be cool, but not strictly necessary. If it were
necessary, then it couldn't be cool.


Or is it okay to demarcate the quote at the start and end as I do?


It disrupts the convention. I would not do this.

--
You won't feel the collar if you don't go anywhere.

Re: [offlist] posting style [was Re: Using .XCompose]

2020-07-07 Thread Andrei POPESCU
On Mi, 08 iul 20, 02:52:02, Ajith R wrote:
> 
> Do I understand the style correctly now?

Mostly. Think of it as "conversational" style, with the reply following 
the portion of text it addresses.

Other text should be removed, unless it provides useful context (would 
your message make sense if read by someone not familiar with the issue 
and without access to previous messages?).

> BTW, a query about how the original message is quoted with '<'. Is it 
> done by hand or does any email clients do it automatically?

Most email clients should do this automatically when you select "plain 
text" mode.

HTML messages may look completely different at the receiving side, which 
is why they should be avoided. One can use other characters for 
emphasis, like *bold*, /italics/, _underline_.

> Is it necessary that each line s marked with '<'? Or is it okay to 
> demarcate the quote at the start and end as I do?

In my opinion the most important part is clearly distinguishing between 
quote and reply, as well as properly attributing quotes (who wrote 
what).

Using '>' makes it easier for list recipients to read your message, e.g.  
my email client is configured to use different colours depending on the 
quote level.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: [offlist] Re: Using .XCompose

2020-07-07 Thread Zenaan Harkness
On Wed, Jul 08, 2020 at 02:59:20AM +, Ajith R wrote:
> Hi David,
> 
> >>>
> As a rule, send replies to the listserv address:
> 
>     debian-user@lists.debian.org
> 
> 2. In-Line replies, instead of Top-Posting
> 3. I apologise for being a Terrible Person


Hey!  I thought I had a patent, trademark _and_ copyright on self deprecation ;)



Re: [offlist] Re: Using .XCompose

2020-07-07 Thread davidson

On Wed, 8 Jul 2020 Ajith R wrote:

Hi David,




As a rule, send replies to the listserv address:

    debian-user@lists.debian.org

2. In-Line replies, instead of Top-Posting
3. I apologise for being a Terrible Person






I didn't pay attention to the fact that the from address in the
email was yours and not that of the list server. I just replied to
the email. I will try to remember to correct the to address


LOL. No big deal either way.


I hope my replies confirm to the Bottom-Line style you suggested in another 
mail.


Working on a reply to that part.


I thank you for showing the patience


No patience required.


to explain to us the newcomers the conventions of this list.


They say that those who cannot, will teach. That might apply in this
case.

--
You won't feel the collar if you don't go anywhere.

Re: [offlist] Re: Using .XCompose

2020-07-07 Thread Ajith R
Hi David,

>>>
As a rule, send replies to the listserv address:

    debian-user@lists.debian.org

2. In-Line replies, instead of Top-Posting
3. I apologise for being a Terrible Person

>>>

I didn't pay attention to the fact that the from address in the email was yours 
and not that of the list server. I just replied to the email. I will try to 
remember to correct the to address

I hope my replies confirm to the Bottom-Line style you suggested in another 
mail.

I thank you for showing the patience to explain to us the newcomers the 
conventions of this list.

Thanks,
ajith



Re: [offlist] posting style [was Re: Using .XCompose]

2020-07-07 Thread Ajith R



Hi David,

>>>
Debian conformant style looks like this instead:
>>>

Do I understand the style correctly now? BTW, a query about how the original 
message is quoted with '<'. Is it done by hand or does any email clients do it 
automatically?  Is it necessary that each line s marked with '<'? Or is it okay 
to demarcate the quote at the start and end as I do?

Thanks,
ajith



Re: Using .XCompose

2020-07-07 Thread davidson

On Wed, 8 Jul 2020 Zenaan Harkness wrote:


I'm not sure if it's been asked or stated by you, but which desktop
are you using?


Elsewhere in the thread,

  
https://lists.debian.org/msgid-search/885539452.3315628.1594115314...@mail.yahoo.com

OP mentions using Konsole and Kate, to test changes made to ~/.XCompose.

So KDE would be my guess. Only a guess, of course. OP will probably
tell us the facts. But if you want my speculation in the meantime,
there you are.

[rest snipped]



Re: Using .XCompose

2020-07-07 Thread Zenaan Harkness
I'm not sure if it's been asked or stated by you, but which desktop are you 
using?  If you're new to Debian, perhaps just the default.

I am using XFCE and in the menu:

   Applications → Settings → Keyboard

there are three tabs "Behaviour", "Application Shortcuts" and "Layout".

Under the "Layout" tab, I have the option for "Compose key" - this is a drop 
down list, and I chose the "Scroll Lock" key as my compose key.

As you can see in the above, I am producing arrows, by pressing:

   "Scroll Lock"  and then  ">"

For my standard US layout, ">" is "Shift + Period".

I don't know this will be useful, but I did not catch that you had checked your 
desktop settings.

Good luck,




On Mon, Jul 06, 2020 at 05:34:59AM +, Ajith R wrote:
> Hi,
> I am new to Linux and Debian.I am trying to build a custom layout for my 
> mother tongue Malayalam (India, Kerala).
> The problem I am trying to tackle:
> One of the Malayalam letters, ങ (U+0D19), is used much more commonly in its 
> geminate form which is composed of three unicode charcters ങ ് ങ (U+0D19 
> U+0D4D U+0D19)  which will yield the geminate form ങ്ങ So, when I type, I 
> want the ങ to be replaced with ങ്ങ.The keyboard layout is working fine as far 
> as I can see. It does yield the correct letters. What doesn't seem to work is 
> the .XCompose mechanism. Please tell me what I am missing.
> Relevant part of my layout file /usr/share/X11/xkb/symbols/in
> ---
> partial alphanumeric_keys
> xkb_symbols "mal_puthuniraA" {
>  name[Group1] = "Malayalam (Puthu Nira Aarambham)";
>  key.type="FOUR_LEVEL";
>  key    { [   U0D41, U0D19, U0D4E, U0D71] }; //  ു MALAYALAM VOWEL SIGN 
> U, ങ്ങ MALAYALAM LETTER NGA geminate form,  ൎMALAYALAM LETTER DOT REPH,  ൱ 
> MALAYALAM NUMBER ONE HUNDRED include "level3(ralt_switch)"
> };--
> My .XCompose file in my home directory is-include "%L" 
>   : "ങ്ങ"
>  : "ങ്ങ"
> ങ : "ങ്ങ"-
> I found the name XK_Shift_L in keysymdef.h file. I tried the unicode 
> character and its code as well to identify the keypress. I tried with only 
> one of the lines as well. XCompose(3) — libx11-doc — Debian buster — Debian 
> Manpages was consulted. I have tried restarting after making changes which 
> didn't help. 
> Am I referring to the keypress correctly? What am I missing?
> Thanks for your help,ajith
> 
> 
> | 
> | 
> | 
> |  |  |
> 
>  |
> 
>  |
> | 
> |  | 
> XCompose(3) — libx11-doc — Debian buster — Debian Manpages
> 
> 
>  |
> 
>  |
> 
>  |
> 
> 
> 
> 



Re: Using .XCompose

2020-07-07 Thread Ajith R
 Hi,
From the above, it sounds to me that you are saying you would like a
*single* keypress to result in entry of the above geminate form. Do I
understand you correctly?Yes, perfectly.
And if so, are you setting aside the question of how to enter the
simple glyph

  ങ (U+0D19)

as an exercise for later?
No. I have achieved that already. I have defined a custom layout which seems to 
work ok. Among other lines, this line in the layout file is relevant to the 
character I am talking
 key   { [  U0D41, U0D19, U0D4E, U0D71] }; 

I lack expertise, but am interested.Your help is very much appreciated

So one change you could try, would be to replace
  
with
  
in the line above.
After reading your reply in another mail, I tried that; didn't work. I tried a 
composing example from the files in the link you provided but couldn't get 
composing to work (I have given the details in another mail). I suspect that I 
am missing something basic (I have named the file .XCompose and it is in my 
home folder). Should it have a particular start or end? To test composing, my 
.XCompose is just include "%L" 
   : "✄"   U2704 # WHITE SCISSORS
Thanks,ajith
On Tuesday, 7 July, 2020, 2:07:52 am IST, davidson  
wrote:  
 
 On Mon, 6 Jul 2020 davidson wrote:
> On Mon, Jul 06, 2020 at 05:34:59AM +, Ajith R wrote:
[snip]

>> I am trying to build a custom layout for my mother tongue Malayalam
>> (India, Kerala).
[snip]

>> The problem I am trying to tackle:
>> 
>> One of the Malayalam letters, ങ (U+0D19), is used much more commonly
>> in its geminate form which is composed of three unicode charcters
>>
>>  ങ  ്ങ (U+0D19 U+0D4D U+0D19)
>> 
>> which will yield the geminate form
>>
>>  ങ്ങ
>> 
>> So, when I type, I want the ങ to be replaced with ങ്ങ.
           ^ 

>From the above, it sounds to me that you are saying you would like a
*single* keypress to result in entry of the above geminate form. Do I
understand you correctly?

And if so, are you setting aside the question of how to enter the
simple glyph

  ങ (U+0D19)

as an exercise for later?

I am still working towards interpreting (1) what you've done so far,
(2) what exactly you want to achieve, and (3) figuring out how I'd
solve some similar problem.

I lack expertise, but am interested.

>> The keyboard layout is working fine as far as I can see. It does
>> yield the correct letters. What doesn't seem to work is the
>> .XCompose mechanism. Please tell me what I am missing.

Not sure yet. In the meantime, I have one trivial observation to make,
below.

>> Relevant part of my layout file /usr/share/X11/xkb/symbols/in
>> ---
>> partial alphanumeric_keys
>> xkb_symbols "mal_puthuniraA" {
>>      name[Group1] = "Malayalam (Puthu Nira Aarambham)";
>>      key.type="FOUR_LEVEL";
>>  key   { [  U0D41, U0D19, U0D4E, U0D71] }; //  ുMALAYALAM VOWEL 
>> SIGN U, ങ്ങ MALAYALAM LETTER NGA geminate form,  ൎMALAYALAM LETTER DOT REPH, 
>> ൱ MALAYALAM NUMBER ONE HUNDRED
>>  include "level3(ralt_switch)"
>> };
>> --
>> My .XCompose file in my home directory is
>> -
>> include "%L"
>>   : "ങ്ങ"

In XCompose(3), under FILE FORMAT, I read:

  "Keysyms are specified without the XK_ prefix."

So one change you could try, would be to replace

  

with

  

in the line above.

>>  : "ങ്ങ"
>> ങ : "ങ്ങ"
>> -
>> I found the name XK_Shift_L in keysymdef.h file. I tried the unicode 
>> character and its code as well to
>> identify the keypress. I tried with only one of the lines as well.
>> XCompose(3) — libx11-doc — Debian buster — Debian Manpages was consulted. I 
>> have tried restarting after
>> making changes which didn't help.
>> Am I referring to the keypress correctly? What am I missing?
>> Thanks for your help,
>> ajith
>>
>>                        XCompose(3) — libx11-doc — Debian buster — Debian 
>> Manpages

-- 
What do you want to take off? [hrzF or ?*] F
You were wearing a +0 robe.  The frost giant turns to flee.  

Re: Using .XCompose

2020-07-07 Thread Ajith R
 Hi,
I test it by typing the letter from the keyboard (using shift / without it 
based on the layout specification) from the same terminal (Konsole) that i use 
setxkbmap to change to my layout. Then I run another terminal using the desktop 
link and try tying it. Then I try in Kate. And finally I reboot and try in Kate 
again.ajith

On Tuesday, 7 July, 2020, 12:04:46 pm IST, davidson  
wrote:  
 
 On Mon, 6 Jul 2020 davidson wrote:
> On Mon, Jul 06, 2020 at 05:34:59AM +, Ajith R wrote:
[snip]

>> The problem I am trying to tackle:
>> 
>> One of the Malayalam letters, ങ (U+0D19), is used much more commonly
>> in its geminate form which is composed of three unicode charcters
>>
>>  ങ  ്ങ (U+0D19 U+0D4D U+0D19)
>> 
>> which will yield the geminate form
>>
>>  ങ്ങ
>> 
>> So, when I type, I want the ങ to be replaced with ങ്ങ.
>> 
>> The keyboard layout is working fine as far as I can see. It does
>> yield the correct letters. What doesn't seem to work is the
>> .XCompose mechanism.

One thing that would be helpful for us to know: How are you *testing*
whether the .XCompose mechanism "works"?

That is, after making changes to the ~/.XCompose file, what
applications do you use for testing? Do you use xterm?  Some other
terminal emulator?  Firefox? Several applications?  Which ones? Do
they all yield the same results?

>> Please tell me what I am missing.
[snip]

-- 
What do you want to take off? [hrzF or ?*] F
You were wearing a +0 robe.  The frost giant turns to flee.  

Re: Using .XCompose

2020-07-07 Thread Greg Wooledge
On Tue, Jul 07, 2020 at 09:44:38AM +, Ajith R wrote:
> I copied one line from your keyboard configuration file and  my keyboard file 
> looks like this now :# KEYBOARD CONFIGURATION FILE
> 
> XKBMODEL="pc105"
> XKBLAYOUT="in"
> XKBVARIANT="eng"
> XKBOPTIONS="lv3:ralt_switch,compose:caps,terminate:ctrl_alt_bksp"
> 
> BACKSPACE="guess"
> 
> and my .XCompose file now is 
> include "%L" 
>    : "✄"   U2704 # WHITE SCISSORS
> 
> However, when I press Caps Lock followed by s and then x or if I keep the 
> Caps Lock pressed while I press s and x in sequence, I don't get scissors. I 
> get S and X

I have no experience with modifying /etc/default/keyboard.
Does your Caps Lock key work for Compose if you set it with:

xmodmap -e "keysym Caps_Lock = Multi_key"

Also, as mentioned before, please make sure you open a new terminal
(or other X11 application) after modifying your .XCompose file.  That
file is only read when libx11 initializes during the start of a new
client application.



Re: Using .XCompose

2020-07-07 Thread Ajith R
 Hi David,
Thanks for your reply.I presume XCompose(3) is a typo for 5, the file 
format section.
There you will find that you don't use the XK_ prefix here.
I was looking at XCompose(3). Thanks for pointing out the mistake.

As I understand .XCompose, it is designed for "compositing", so each
key on the left side should be a "normal" keystroke. Typically the
LeftShift modifies the letter keys: in English, it makes "a" into "A".
So you wouldn't want to use it in a compositing sequence because you
would lose its normal shift function.I understand that. My letter is in the 
'shift' set of keystrokes. That was the reason I included it. Moreover, the 
Compose manual page states that 
'Each event consists of a specified input keysym, and optional modifier states:
[([!] ([~] MODIFIER)...) | None] ". '

I was just trying to find out the reason why the 'composting' was not working. 
I tried including the modifier name and also without it. I tried moving the key 
to the first layer of keyboard layout (without shift or other modifiers). Even 
that was not working. So, I was wondering if there was a syntax error in the 
way I was specifying my requirement. I understand the use of Compose key. But, 
I was not trying the usual 'composting' (by means of a compose key). I  want 
one character to be replaced with its geminate form whenever it is typed. If 
the keyboard layout specification allowed more than one character for a 
keystroke, I wouldn't have needed it. Hence the need for Compose mechanism. A 
similar approach is explained here https://dominiko.livejournal.com/20206.html 
. However in it, the author has defined a personal use Unicode character, but I 
use one of the Unicode defined characters. In the symbol file, he had used key 
 { type[group1] = "FOUR_LEVEL_C_HWERTY", 
    [    UF8FD,  UF8FE,   UF8FF,    
Greek_alpha ] };
I didn't understand the use of type[group1 = "..."], but thought that it was 
not essential. Anyway, the layout is working as expected in that the characters 
returned by layout is as defined. 
The compose mechanism is not working.
I copied one line from your keyboard configuration file and  my keyboard file 
looks like this now :# KEYBOARD CONFIGURATION FILE

XKBMODEL="pc105"
XKBLAYOUT="in"
XKBVARIANT="eng"
XKBOPTIONS="lv3:ralt_switch,compose:caps,terminate:ctrl_alt_bksp"

BACKSPACE="guess"

and my .XCompose file now is 
include "%L" 
   : "✄"   U2704 # WHITE SCISSORS

However, when I press Caps Lock followed by s and then x or if I keep the Caps 
Lock pressed while I press s and x in sequence, I don't get scissors. I get S 
and X

So, my computer's  compose mechanism is not working. Is there something wrong 
in what I am doing or am I missing something? Other than creating the .XCompose 
file in the home folder, should I tell the system in some way that the compose 
mechanism should be activated? (BTW, I tried restarting the computer after the 
change).

I am running Debian 10, KDE Plasma  5.14.5, 64 bit

Thanks,ajith
On Tuesday, 7 July, 2020, 4:00:50 am IST, David Wright 
 wrote:  
 
 On Mon 06 Jul 2020 at 05:34:59 (+), Ajith R wrote:

> My .XCompose file in my home directory is-include "%L" 
>   : "ങ്ങ"
>  : "ങ്ങ"
> ങ : "ങ്ങ"-
> I found the name XK_Shift_L in keysymdef.h file. I tried the unicode 
> character and its code as well to identify the keypress. I tried with only 
> one of the lines as well. XCompose(3) — libx11-doc — Debian buster — Debian 
> Manpages was consulted. I have tried restarting after making changes which 
> didn't help. 
> Am I referring to the keypress correctly? What am I missing?

I presume XCompose(3) is a typo for 5, the file format section.
There you will find that you don't use the XK_ prefix here.

As I understand .XCompose, it is designed for "compositing", so each
key on the left side should be a "normal" keystroke. Typically the
LeftShift modifies the letter keys: in English, it makes "a" into "A".
So you wouldn't want to use it in a compositing sequence because you
would lose its normal shift function.

Usually you select a "Compose" key, and that is used here under the name
 in .XCompose, and in the system's Compose file,
/usr/share/X11/locale/…/Compose where … is a locale's name.
Mine, for example, is CapsLock, because I don't make a habit of typing
in All Caps. That is set in /etc/default/keyboard:
XKBOPTIONS="lv3:ralt_switch,compose:caps,terminate:ctrl_alt_bksp"
                            

If you peruse your own system's /usr/share/X11/locale/…/Compose file,
which is the one being included by your "%L" above, you'll get an idea
of the best keys to use. I believe many European languages use the
"dead" keys a lot, but because British doesn't, I don't know how those
work. A European might like to comment on this.

In case it's any help, I posted some keyboard configuration files
last year at:

https://lists.debian.org/d

Re: Using .XCompose

2020-07-06 Thread davidson

On Mon, 6 Jul 2020 davidson wrote:

On Mon, Jul 06, 2020 at 05:34:59AM +, Ajith R wrote:

[snip]


The problem I am trying to tackle:

One of the Malayalam letters, ങ (U+0D19), is used much more commonly
in its geminate form which is composed of three unicode charcters

  ങ  ്ങ (U+0D19 U+0D4D U+0D19)

which will yield the geminate form

  ങ്ങ

So, when I type, I want the ങ to be replaced with ങ്ങ.

The keyboard layout is working fine as far as I can see. It does
yield the correct letters. What doesn't seem to work is the
.XCompose mechanism.


One thing that would be helpful for us to know: How are you *testing*
whether the .XCompose mechanism "works"?

That is, after making changes to the ~/.XCompose file, what
applications do you use for testing? Do you use xterm?  Some other
terminal emulator?  Firefox? Several applications?  Which ones? Do
they all yield the same results?


Please tell me what I am missing.

[snip]

--
What do you want to take off? [hrzF or ?*] F
You were wearing a +0 robe.  The frost giant turns to flee.

Re: tangent on man page locations [was Re: Using .XCompose]

2020-07-06 Thread David Wright
On Mon 06 Jul 2020 at 23:08:29 (+), davidson wrote:
> On Mon, 6 Jul 2020 David Wright wrote:
> 
> > I presume XCompose(3) is a typo for 5, the file format section.
> 
> Probably not. Here we have
> […]
> and hence
> 
>   $ man -w 3 XCompose
>   /usr/share/man/man5/Compose.5.gz
> 
>   $ man -w 5 XCompose
>   /usr/share/man/man5/Compose.5.gz
> 
> Which is to say, XCompose(5) and XCompose(3) refer to the same
> document.

Fair enough; I didn't know someone had dropped this alias into
section 3; it certainly looks out of place. But I keep well away
from X11 calls, and hence libx11-doc, and would advise the OP
to do so also:

Package: libx11-doc
Description-en: X11 client-side library (development documentation)
 This package provides a client interface to the X Window System, otherwise
 known as 'Xlib'.  It provides a complete API for the basic functions of the
 window system.
 This package contains supplemental documentation for the library found in
 libx11-6. Non-developers likely have little use for this package.

Having just looked at the OP again (via the HTML this time),
I see there's an external link to that library (which my lynx
suppresses). So it's possible the OP hasn't installed libx11-doc.

Cheers,
David.



tangent on man page locations [was Re: Using .XCompose]

2020-07-06 Thread davidson

On Mon, 6 Jul 2020 David Wright wrote:


I presume XCompose(3) is a typo for 5, the file format section.


Probably not. Here we have

  $ zcat /usr/share/man/man3/XCompose.3.gz
  .so man5/Compose.5

  $ realpath /usr/share/man/man5/XCompose.5.gz
  /usr/share/man/man5/Compose.5.gz

and hence

  $ man -w 3 XCompose
  /usr/share/man/man5/Compose.5.gz

  $ man -w 5 XCompose
  /usr/share/man/man5/Compose.5.gz

Which is to say, XCompose(5) and XCompose(3) refer to the same
document.

--
What do you want to take off? [hrzF or ?*] F
You were wearing a +0 robe.  The frost giant turns to flee.



Re: Using .XCompose

2020-07-06 Thread David Wright
On Mon 06 Jul 2020 at 05:34:59 (+), Ajith R wrote:

> My .XCompose file in my home directory is-include "%L" 
>   : "ങ്ങ"
>  : "ങ്ങ"
> ങ : "ങ്ങ"-
> I found the name XK_Shift_L in keysymdef.h file. I tried the unicode 
> character and its code as well to identify the keypress. I tried with only 
> one of the lines as well. XCompose(3) — libx11-doc — Debian buster — Debian 
> Manpages was consulted. I have tried restarting after making changes which 
> didn't help. 
> Am I referring to the keypress correctly? What am I missing?

I presume XCompose(3) is a typo for 5, the file format section.
There you will find that you don't use the XK_ prefix here.

As I understand .XCompose, it is designed for "compositing", so each
key on the left side should be a "normal" keystroke. Typically the
LeftShift modifies the letter keys: in English, it makes "a" into "A".
So you wouldn't want to use it in a compositing sequence because you
would lose its normal shift function.

Usually you select a "Compose" key, and that is used here under the name
 in .XCompose, and in the system's Compose file,
/usr/share/X11/locale/…/Compose where … is a locale's name.
Mine, for example, is CapsLock, because I don't make a habit of typing
in All Caps. That is set in /etc/default/keyboard:
XKBOPTIONS="lv3:ralt_switch,compose:caps,terminate:ctrl_alt_bksp"


If you peruse your own system's /usr/share/X11/locale/…/Compose file,
which is the one being included by your "%L" above, you'll get an idea
of the best keys to use. I believe many European languages use the
"dead" keys a lot, but because British doesn't, I don't know how those
work. A European might like to comment on this.

In case it's any help, I posted some keyboard configuration files
last year at:

https://lists.debian.org/debian-user/2019/07/msg00926.html

The first section is an incomplete set of function keys for my window
manager; the next section defines keys for VCs (where I include the
system defaults to preserve them); following that is my .XCompose.
The system defaults already include most of what I want, so I add
only 14 more. The final section is a few definitions from my emacs
configuration.

Cheers,
David.



Re: Using .XCompose

2020-07-06 Thread davidson

On Mon, 6 Jul 2020 davidson wrote:

On Mon, Jul 06, 2020 at 05:34:59AM +, Ajith R wrote:

[snip]


I am trying to build a custom layout for my mother tongue Malayalam
(India, Kerala).

[snip]


The problem I am trying to tackle:

One of the Malayalam letters, ങ (U+0D19), is used much more commonly
in its geminate form which is composed of three unicode charcters

  ങ  ്ങ (U+0D19 U+0D4D U+0D19)

which will yield the geminate form

  ങ്ങ

So, when I type, I want the ങ to be replaced with ങ്ങ.

  ^ 


From the above, it sounds to me that you are saying you would like a

*single* keypress to result in entry of the above geminate form. Do I
understand you correctly?

And if so, are you setting aside the question of how to enter the
simple glyph

 ങ (U+0D19)

as an exercise for later?

I am still working towards interpreting (1) what you've done so far,
(2) what exactly you want to achieve, and (3) figuring out how I'd
solve some similar problem.

I lack expertise, but am interested.


The keyboard layout is working fine as far as I can see. It does
yield the correct letters. What doesn't seem to work is the
.XCompose mechanism. Please tell me what I am missing.


Not sure yet. In the meantime, I have one trivial observation to make,
below.


Relevant part of my layout file /usr/share/X11/xkb/symbols/in
---
partial alphanumeric_keys
xkb_symbols "mal_puthuniraA" {
 name[Group1] = "Malayalam (Puthu Nira Aarambham)";
 key.type="FOUR_LEVEL";
 key{ [   U0D41, U0D19, U0D4E, U0D71] }; //   ുMALAYALAM VOWEL 
SIGN U, ങ്ങ MALAYALAM LETTER NGA geminate form,  ൎMALAYALAM LETTER DOT REPH, 
൱ MALAYALAM NUMBER ONE HUNDRED

 include "level3(ralt_switch)"
};
--
My .XCompose file in my home directory is
-
include "%L"
  : "ങ്ങ"


In XCompose(3), under FILE FORMAT, I read:

  "Keysyms are specified without the XK_ prefix."

So one change you could try, would be to replace

  

with

  

in the line above.


 : "ങ്ങ"
ങ : "ങ്ങ"
-
I found the name XK_Shift_L in keysymdef.h file. I tried the unicode 
character and its code as well to

identify the keypress. I tried with only one of the lines as well.
XCompose(3) — libx11-doc — Debian buster — Debian Manpages was consulted. I 
have tried restarting after

making changes which didn't help.
Am I referring to the keypress correctly? What am I missing?
Thanks for your help,
ajith

   XCompose(3) — libx11-doc — Debian buster — Debian 
Manpages


--
What do you want to take off? [hrzF or ?*] F
You were wearing a +0 robe.  The frost giant turns to flee.

Re: Using .XCompose

2020-07-06 Thread davidson

On Mon, Jul 06, 2020 at 05:34:59AM +, Ajith R wrote:

Hi,
I am new to Linux and Debian.


That is good news. Welcome.


I am trying to build a custom layout for my mother tongue Malayalam
(India, Kerala).


That sounds like an interesting challenge.

Your original message appears to be in html format. The subscribers to
this mailing list use a great variety of clients to read the messages
here. Many of these clients display only plain text, and some of them
(such as my own) will tend to mangle html messages beyond recognition,
in a heroic effort to transform html into plain text.

It is therefore the convention on this list to send plain text
messages only. If you are able to conform to this convention, your
messages will reach a wider audience, and you may get more --and
better-- responses as a result.

The rest of my reply is merely the remainder of your original message,
--quoted, but converted to plain text (using the lynx text browser)--
for the benefit of subscribers who, like me, use mail clients (eg,
alpine) which badly mangled the original.

(NB: Setting up an environment that displays Malayalam glyphs as
intended is a separate matter, outside my scope here.)

Good luck with your project.


The problem I am trying to tackle:

One of the Malayalam letters, ങ (U+0D19), is used much more commonly
in its geminate form which is composed of three unicode charcters

  ങ ് ങ (U+0D19 U+0D4D U+0D19)

which will yield the geminate form

  ങ്ങ

So, when I type, I want the ങ to be replaced with ങ്ങ.

The keyboard layout is working fine as far as I can see. It does
yield the correct letters. What doesn't seem to work is the
.XCompose mechanism. Please tell me what I am missing.

Relevant part of my layout file /usr/share/X11/xkb/symbols/in
---
partial alphanumeric_keys
xkb_symbols "mal_puthuniraA" {
 name[Group1] = "Malayalam (Puthu Nira Aarambham)";
 key.type="FOUR_LEVEL";
 key{ [   U0D41, U0D19, U0D4E, U0D71] }; //  ു MALAYALAM VOWEL SIGN U, ങ്ങ MALAYALAM LETTER 
NGA geminate form,  ൎMALAYALAM LETTER DOT REPH,  ൱ MALAYALAM NUMBER ONE HUNDRED

 include "level3(ralt_switch)"
};
--
My .XCompose file in my home directory is
-
include "%L"
  : "ങ്ങ"
 : "ങ്ങ"
ങ : "ങ്ങ"
-
I found the name XK_Shift_L in keysymdef.h file. I tried the unicode character 
and its code as well to
identify the keypress. I tried with only one of the lines as well.
XCompose(3) — libx11-doc — Debian buster — Debian Manpages was consulted. I 
have tried restarting after
making changes which didn't help.
Am I referring to the keypress correctly? What am I missing?
Thanks for your help,
ajith

   XCompose(3) — libx11-doc — Debian buster — Debian 
Manpages


--
What do you want to take off? [hrzF or ?*] F
You were wearing a +0 robe.  The frost giant turns to flee.

Re: Using .XCompose

2020-07-06 Thread Zenaan Harkness
On Mon, Jul 06, 2020 at 05:34:59AM +, Ajith R wrote:
> Hi,
> I am new to Linux and Debian.I am trying to build a custom layout for my 
> mother tongue Malayalam (India, Kerala).
> The problem I am trying to tackle:
> One of the Malayalam letters, ങ (U+0D19), is used much more commonly in its 
> geminate form which is composed of three unicode charcters ങ ് ങ (U+0D19 
> U+0D4D U+0D19)  which will yield the geminate form ങ്ങ So, when I type, I 
> want the ങ to be replaced with ങ്ങ.The keyboard layout is working fine as far 
> as I can see. It does yield the correct letters. What doesn't seem to work is 
> the .XCompose mechanism. Please tell me what I am missing.

I have a little experience only with X layout files and not the compose 
mechanism.  When you solve this, please post your solution here :)



Re: Using .XCompose

2020-07-06 Thread Greg Wooledge
On Mon, Jul 06, 2020 at 05:34:59AM +, Ajith R wrote:
> I am new to Linux and Debian.I am trying to build a custom layout for my 
> mother tongue Malayalam (India, Kerala).

Sadly, I know almost nothing about Asian languages.

Does  help you?  If it's just a handful
of characters that are giving you trouble, this might be an adequate
solution.