Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Modify text appearance (put spaces after commas just for display)

2 views
Skip to first unread message

Alberto Luaces

unread,
Oct 2, 2017, 4:15:02 PM10/2/17
to help-gn...@gnu.org
Hello, I have some inherited code where the style used was to squeeze
every single non-required white-space. There are long lists of
comma-separated values with any spaces on them, rendering the code very
difficult to read.

I wanted to have something like glasses-mode, but unless I am mistaken,
it is not very configurable, so I cannot add new cases as commas
separated by spaces, which is mine.

Then I thought of overlays, but the manual says that if there are a big
number of substitutions, maybe it could be a better idea to use text
properties instead.

So, from the top of your head, what would be the less painful method to
change every comma to a comma+space, or at least change the color of the
commas to anything more distinguishable and attach it to the language
mode hook?

Thanks!

--
Alberto


Alberto Luaces

unread,
Oct 2, 2017, 4:15:04 PM10/2/17
to help-gn...@gnu.org
Emanuel Berg writes:
> ... you mean in code that is already written?
>
> Do it by hand, or use `replace-regexp'.
>
> (replace-regexp "," ", ")

Yes, it is already written.

The point is not modifying the code, as in glasses-mode style, so
replace-regexp is not a solution. Thanks anyway!

--
Alberto


Emanuel Berg

unread,
Oct 2, 2017, 4:15:04 PM10/2/17
to help-gn...@gnu.org
Alberto Luaces wrote:

> Hello, I have some inherited code where the
> style used was to squeeze every single
> non-required white-space. There are long
> lists of comma-separated values with any
> spaces on them, rendering the code very
> difficult to read.
>
> I wanted to have something like glasses-mode,
> but unless I am mistaken, it is not very
> configurable, so I cannot add new cases as
> commas separated by spaces, which is mine.
>
> Then I thought of overlays, but the manual
> says that if there are a big number of
> substitutions, maybe it could be a better
> idea to use text properties instead.
>
> So, from the top of your head, what would be
> the less painful method to change every comma
> to a comma+space, or at least change the
> color of the commas to anything more
> distinguishable and attach it to the language
> mode hook?

... you mean in code that is already written?

Do it by hand, or use `replace-regexp'.

(replace-regexp "," ", ")

--
underground experts united
http://user.it.uu.se/~embe8573


to...@tuxteam.de

unread,
Oct 2, 2017, 4:15:05 PM10/2/17
to help-gn...@gnu.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Sep 26, 2017 at 11:28:35AM +0200, Emanuel Berg wrote:
> Alberto Luaces wrote:

[...]

> ... you mean in code that is already written?
>
> Do it by hand, or use `replace-regexp'.
>
> (replace-regexp "," ", ")

I think the OP didn't want to change the text itself, but just its
display/appearance. Like with display properties.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnKHscACgkQBcgs9XrR2kbLgQCeL5N7P1g2joPQouMs06G1ecJ6
qQEAn1GZFT/QVilhNhlAKYZVuEcNra0v
=UCKe
-----END PGP SIGNATURE-----

Yuri Khan

unread,
Oct 2, 2017, 4:15:10 PM10/2/17
to Alberto Luaces, help-gn...@gnu.org
On Tue, Sep 26, 2017 at 4:12 PM, Alberto Luaces <alu...@udc.es> wrote:

> So, from the top of your head, what would be the less painful method to
> change every comma to a comma+space, or at least change the color of the
> commas to anything more distinguishable and attach it to the language
> mode hook?

One imperfect approximation would be to use prettify-symbols-mode.

$ emacs -Q

(add-to-list 'prettify-symbols-alist '("," . (?, (Br . Bl) ?\s)))

M-x prettify-symbols-mode RET

Limitations:

* Does not act on commas in comments or string literals.
* If a comma is followed by a space, you will see two spaces.

If you want to overcome these, you will either want to write some
custom predicates for prettify-symbols-mode, or dive a layer down and
work with ‘font-lock-add-keywords’ directly.

Emanuel Berg

unread,
Oct 2, 2017, 4:15:11 PM10/2/17
to help-gn...@gnu.org
tomás wrote:

> I think the OP didn't want to change the text
> itself, but just its display/appearance.

So it will look one way and be another?
Why would you do that?

to...@tuxteam.de

unread,
Oct 2, 2017, 4:15:12 PM10/2/17
to help-gn...@gnu.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Sep 26, 2017 at 12:14:05PM +0200, Emanuel Berg wrote:
> tomás wrote:
>
> > I think the OP didn't want to change the text
> > itself, but just its display/appearance.
>
> So it will look one way and be another?
> Why would you do that?

Why wouldn't you?

(yah, snotty reply, sorry. What I mean is... we do that all the time,
with syntax highlighting, moving the debugger "spot" around, Customize
(yes, we know you don't like that one). If you press me, hey, UTF-8.

What you see in your editor is already the result of layers upon layers
of representation and cheating (newline? tab? C'm on! ;)

The nice thing about Emacs is that it not only caters for my (or your)
needs :-)

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnKLEAACgkQBcgs9XrR2kbc7QCdEJ4QpHh8YJ1DWh+koi+2vMYE
pTMAnj2neUW7hdsiIELAXtA3k9JCLbqH
=EPUc
-----END PGP SIGNATURE-----

Alberto Luaces

unread,
Oct 2, 2017, 4:15:13 PM10/2/17
to help-gn...@gnu.org
Yuri Khan writes:

> On Tue, Sep 26, 2017 at 4:12 PM, Alberto Luaces <alu...@udc.es> wrote:
>
>> So, from the top of your head, what would be the less painful method to
>> change every comma to a comma+space, or at least change the color of the
>> commas to anything more distinguishable and attach it to the language
>> mode hook?
>
> One imperfect approximation would be to use prettify-symbols-mode.
>
> $ emacs -Q
>
> (add-to-list 'prettify-symbols-alist '("," . (?, (Br . Bl) ?\s)))
>
> M-x prettify-symbols-mode RET
>
> Limitations:
>
> * Does not act on commas in comments or string literals.
> * If a comma is followed by a space, you will see two spaces.
>

Nice solution, thanks! The limitations are fine by me, since I do not
care about the comments, and having several spaces together does not
hinder my reading.

I like very much how emacs keeps considering the substituted character
as a whole block, so that eases the editing of the file since I know
which spaces are real and which ones are not.

> If you want to overcome these, you will either want to write some
> custom predicates for prettify-symbols-mode, or dive a layer down and
> work with ‘font-lock-add-keywords’ directly.
>

Nice to know. Thanks again!

--
Alberto


Alberto Luaces

unread,
Oct 2, 2017, 4:15:14 PM10/2/17
to help-gn...@gnu.org
tomás writes:

> On Tue, Sep 26, 2017 at 12:14:05PM +0200, Emanuel Berg wrote:
>> tomás wrote:
>>
>> > I think the OP didn't want to change the text
>> > itself, but just its display/appearance.
>>
>> So it will look one way and be another?
>> Why would you do that?
>
> Why wouldn't you?
>
> (yah, snotty reply, sorry. What I mean is... we do that all the time,
> with syntax highlighting, moving the debugger "spot" around, Customize
> (yes, we know you don't like that one). If you press me, hey, UTF-8.
>
> What you see in your editor is already the result of layers upon layers
> of representation and cheating (newline? tab? C'm on! ;)
>
> The nice thing about Emacs is that it not only caters for my (or your)
> needs :-)

Yes, tomás is right with his complete explanation. I would just add
another hint:

glasses-mode

read about it and you will find the entire rationale :-)

--
Alberto


Marcin Borkowski

unread,
Oct 2, 2017, 4:15:17 PM10/2/17
to Alberto Luaces, help-gn...@gnu.org

On 2017-09-26, at 13:05, Alberto Luaces <alu...@udc.es> wrote:

>> If you want to overcome these, you will either want to write some
>> custom predicates for prettify-symbols-mode, or dive a layer down and
>> work with ‘font-lock-add-keywords’ directly.
>
> Nice to know. Thanks again!

How about this?

http://mbork.pl/2016-01-30_Dimming_out_tildes_in_AUCTeX

Hth,

--
Marcin Borkowski

Nick Helm

unread,
Oct 2, 2017, 4:15:19 PM10/2/17
to help-gn...@gnu.org
Alberto Luaces <alu...@udc.es> writes:

> Hello, I have some inherited code where the style used was to squeeze
> every single non-required white-space. There are long lists of
> comma-separated values with any spaces on them, rendering the code very
> difficult to read.
>
> So, from the top of your head, what would be the less painful method to
> change every comma to a comma+space, or at least change the color of the
> commas to anything more distinguishable and attach it to the language
> mode hook?

Another option is to alter the buffer's display table by repurposing
whitespace-mode. For example:

(add-hook 'text-mode-hook (lambda ()
(set (make-local-variable 'whitespace-style) '(space-mark))
(set (make-local-variable 'whitespace-display-mappings)
'((space-mark 44 [44 32])))
(whitespace-mode)))

Change the hook to the language mode you're using. M-x whitespace-mode
toggles the effect off and on, as usual.

--
Nick

Sivaram Neelakantan

unread,
Oct 2, 2017, 4:15:20 PM10/2/17
to help-gn...@gnu.org
On Tue, Sep 26 2017,Alberto Luaces wrote:


[snipped 8 lines]

>
> Then I thought of overlays, but the manual says that if there are a big
> number of substitutions, maybe it could be a better idea to use text
> properties instead.
>
> So, from the top of your head, what would be the less painful method to
> change every comma to a comma+space, or at least change the color of the
> commas to anything more distinguishable and attach it to the language
> mode hook?
>

Does org-mode have a means of making columns out of comma separated
entries just for viewing? I vaguely remember that Excel style columns
were produced on CSV rows when in org-mode


sivaram
--


Alberto Luaces

unread,
Oct 2, 2017, 4:15:30 PM10/2/17
to help-gn...@gnu.org
Nick Helm writes:

> Alberto Luaces <alu...@udc.es> writes:
>
>> Hello, I have some inherited code where the style used was to squeeze
>> every single non-required white-space. There are long lists of
>> comma-separated values with any spaces on them, rendering the code very
>> difficult to read.
>>
>> So, from the top of your head, what would be the less painful method to
>> change every comma to a comma+space, or at least change the color of the
>> commas to anything more distinguishable and attach it to the language
>> mode hook?
>
> Another option is to alter the buffer's display table by repurposing
> whitespace-mode. For example:
>
> (add-hook 'text-mode-hook (lambda ()
> (set (make-local-variable 'whitespace-style) '(space-mark))
> (set (make-local-variable 'whitespace-display-mappings)
> '((space-mark 44 [44 32])))
> (whitespace-mode)))
>
> Change the hook to the language mode you're using. M-x whitespace-mode
> toggles the effect off and on, as usual.

That is nice, Nick. Besides that, I have learned that whitespace-mode
can be customized so deeply thanks to you!

--
Alberto


Alberto Luaces

unread,
Oct 2, 2017, 4:15:32 PM10/2/17
to help-gn...@gnu.org
Yes, I also like your solution, it is very elegant. Thanks, Marcin!

--
Alberto


Alberto Luaces

unread,
Oct 2, 2017, 4:15:32 PM10/2/17
to help-gn...@gnu.org
Sivaram Neelakantan writes:

> On Tue, Sep 26 2017,Alberto Luaces wrote:
>
>
> [snipped 8 lines]
>
>>
>> Then I thought of overlays, but the manual says that if there are a big
>> number of substitutions, maybe it could be a better idea to use text
>> properties instead.
>>
>> So, from the top of your head, what would be the less painful method to
>> change every comma to a comma+space, or at least change the color of the
>> commas to anything more distinguishable and attach it to the language
>> mode hook?
>>
>
> Does org-mode have a means of making columns out of comma separated
> entries just for viewing? I vaguely remember that Excel style columns
> were produced on CSV rows when in org-mode

I think that you are right on this one. Unfortunately, my documents are
source code, and I wanted not to have to transform them manually if
possible, but in an automatic way as some other posters have taught me.

Thanks anyway, Sivaram!

--
Alberto


Emanuel Berg

unread,
Oct 2, 2017, 4:15:40 PM10/2/17
to help-gn...@gnu.org
tomás wrote:

> Why wouldn't you?

Because it is confusing. Just looking at code
tells you a lot. What it is, if there are bugs.
And not just actively. It stores an image in
the brain for later use, if need be.

If you can't trust your eyes, or have to think
(translate in your brain) what it actually is,
that's either a huge disadvantage or an extra
effort which is error-prone and has no
advantage to it.

It also makes the "brain image storage"
much more difficult.

> (yah, snotty reply, sorry. What I mean is...
> we do that all the time, with syntax
> highlighting

The analogue situation with respect to syntax
highlighting would be syntax highlighting that
is inconsistent.

> moving the debugger "spot" around

Likewise, if the spot showed what isn't
"spotted", that'd be analogue.

> Customize (yes, we know you don't like that
> one). If you press me, hey, UTF-8.

Not following?

> What you see in your editor is already the
> result of layers upon layers of
> representation and cheating (newline? tab?
> C'm on! ;)

Newline are displayed as is. Again, the example
would rather be a displayed newline where there
isn't one, or a non-displayed one where there
is one.

Tabs shouldn't be used, the exception being
makefiles because they (tabs) are mandatory
there for reasons unknown to me.

> The nice thing about Emacs is that it not
> only caters for my (or your) needs :-)

... what do you mean?

Marcin Borkowski

unread,
Oct 2, 2017, 4:15:45 PM10/2/17
to Emanuel Berg, help-gn...@gnu.org

On 2017-09-26, at 23:29, Emanuel Berg <moa...@zoho.com> wrote:

> Newline are displayed as is. Again, the example
> would rather be a displayed newline where there
> isn't one [...]

A common situation, see visual-line-mode. And for a good reason.

> Tabs shouldn't be used [...]

Seriously?

Best,

--
Marcin Borkowski

Emanuel Berg

unread,
Oct 2, 2017, 4:15:50 PM10/2/17
to help-gn...@gnu.org
Marcin Borkowski wrote:

>> Newline are displayed as is. Again, the
>> example would rather be a displayed newline
>> where there isn't one [...]
>
> A common situation, see visual-line-mode.
> And for a good reason.

Well, I have 72 columns in the ttys where - in
one of the instances - I have Emacs. Actually,
I can only type 69 chars before the annoying
dollar sign appears. In X and xterm, tho
I don't write anything there really, I have
even less - 71 columns. You can find this out
with

$ echo $COLUMNS

So if I can do it, sure most guys could as they
most likely have much more, and no one (?)
has less.

The only scenario where I see your point is if
one was working on a joint project, and some
bozos were writing insanely long lines. If that
ever happened, the only thing to do would be to
assign the application a new background color,
and clone it.

>> Tabs shouldn't be used [...]
>
> Seriously?

What do you think this is for?

(setq-default indent-tabs-mode nil)

(untabify (point-min) (point-max))

Just so a bunch of bozos can put the tabs
back in?

to...@tuxteam.de

unread,
Oct 2, 2017, 4:15:54 PM10/2/17
to help-gn...@gnu.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Sep 26, 2017 at 11:29:08PM +0200, Emanuel Berg wrote:
> tomás wrote:
>
> > Why wouldn't you?
>
> Because it is confusing.

Sorry. Wrong question (the "you" is ambiguous -- it might
mean either "you, Emanuel" or the generic, impersonal "you".
I meant the latter.

[...]

My whole point can be reduced to two things:

(1) what we perceive as "literal display" is already the result
of a more or less complex mapping; its undeniable advantage
is, of course, that it is very conventional and thus large
swaths of that mapping are already well-understood and relatively
stable. But it's no better or worse (and no "truer" or "falser")
than any other display.

(2) there are other needs, views and preferences than the ones
we currently understand. They are as important as ours.

One of the things I really like Emacs for is that, while it carries
the "plain text" paradigm very far (making Emacs, among other things
eminently understandable and hackable [1]), it doesn't close the door
on (2) (for an example on this, see e.g. Widget).

Cheers

[1] The very Org mode is a living proof to that.
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnLktoACgkQBcgs9XrR2kaJZACdHtvztGtmKXQIoFsXcZSJgeem
85IAnRgT6FARFheDX6gRES86vmsq5svP
=jlG5
-----END PGP SIGNATURE-----

to...@tuxteam.de

unread,
Oct 2, 2017, 4:15:55 PM10/2/17
to help-gn...@gnu.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Sep 27, 2017 at 08:23:35AM +0200, Marcin Borkowski wrote:
>
> On 2017-09-26, at 23:29, Emanuel Berg <moa...@zoho.com> wrote:
>
> > Newline are displayed as is. Again, the example
> > would rather be a displayed newline where there
> > isn't one [...]
>
> A common situation, see visual-line-mode. And for a good reason.
>
> > Tabs shouldn't be used [...]
>
> Seriously?

Yeah, that's one of the patterns over which I get my regular spats with
Emanuel. Luckily he's a pretty civilized arguer (hopefully he sees me
likewise):

I practically never use tabs (perhaps none or close to that in the last
15 years). But I'd *never* *ever* dare that sentence "tabs should not
be used". Who am I to forbid you the use of tabs?

If I had a colleague who insisted on tabs, I'd try to listen to her
reasons for tabs, I'd try to offer my reasons against them (always
talking about tabs in source code), and if no conviction happens,
I'd try to cope with the outcome however best.

I think last time around I tried to make my point to Emanuel with
the sentence "generalizations suck" or some such.

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnLlI0ACgkQBcgs9XrR2kbajQCfag64K1AwrOSzzFnuWls02cDe
tdoAn3sPk2KP9bH3WVmiTSYTXd33TI94
=bWh6
-----END PGP SIGNATURE-----

Emanuel Berg

unread,
Oct 2, 2017, 4:16:27 PM10/2/17
to help-gn...@gnu.org
tomás wrote:

> what we perceive as "literal display" is
> already the result of a more or less complex
> mapping; its undeniable advantage is, of
> course, that it is very conventional and thus
> large swaths of that mapping are already
> well-understood and relatively stable.
> But it's no better or worse (and no "truer"
> or "falser") than any other display.

OK, I suppose both are as true. Even a MacOS
GUI is true in that sense. Only the code text
feels more authentic, more genuine because less
hands, and hands that were less
manipulative/commercial, have tinkered with it
(now the comparison being to the MacOS GUI,
nothing else).

Note that this is my first stop (at least in
this thread) in the
philosophy/perception/estethical domain, until
now I only thought of this as
a practical concern.

But yes, being a practical person for so long
trains the eyes, so when I say a new-built wood
shed "looks good", I actually mean it both
ways, it does literally look good, but it also
looks like it is functional, it is easy to get
the wood in and out, the wind will blow thru,
it won't rain on the firewood, the rain water
will be steered away from the yard and the
person getting wood, and the whole shed won't
blow to pieces first thing.

Or conversely, anyone who has awaken in a messy
room and the first steps of the day is to
navigate between empty cans, ash, and empty
pizza boxes, knows what a lousy feeling that is
and remembers that the rest of the day had all
the likelihoods of being just as lousy.

Emanuel Berg

unread,
Oct 2, 2017, 4:16:30 PM10/2/17
to help-gn...@gnu.org
tomás wrote:

> I practically never use tabs (perhaps none or
> close to that in the last 15 years). But I'd
> *never* *ever* dare that sentence "tabs
> should not be used". Who am I to forbid you
> the use of tabs?

Now, straight up and down, unfortunately,
techno-totalitarianism has only been
implemented spot-wise in this realm.

So for the time being, these are just words.
Anyone reading this is most likely still
allowed to use tabs.

> "generalizations suck"

Sometimes :)

to...@tuxteam.de

unread,
Oct 2, 2017, 4:18:26 PM10/2/17
to help-gn...@gnu.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Sep 28, 2017 at 06:42:12PM +0200, Emanuel Berg wrote:
> t wrote:
>
> > Well, those were the real wizards.
>
> Write code like that, can't keep it up for
> months let alone the time it takes to become
> a wizard.
>
> Discontinued algorithm.

Those were the folks around Ken Iverson, of APL fame. I'm certain
they could read code like that (I can't).

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEUEARECAAYFAlnNLvAACgkQBcgs9XrR2kYVWACWPpsk/bI3f9pN+obsclK6CuOO
IACfVgYj9XPrzvnEo3oAeN6V54PnjLw=
=qbGc
-----END PGP SIGNATURE-----

to...@tuxteam.de

unread,
Oct 2, 2017, 4:18:29 PM10/2/17
to help-gn...@gnu.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Sep 27, 2017 at 11:40:14PM +0200, Emanuel Berg wrote:
> tomás wrote:
>
> > I practically never use tabs (perhaps none or
> > close to that in the last 15 years). But I'd
> > *never* *ever* dare that sentence "tabs
> > should not be used". Who am I to forbid you
> > the use of tabs?
>
> Now, straight up and down, unfortunately,
> techno-totalitarianism has only been
> implemented spot-wise in this realm.

Phew ;-)

> So for the time being, these are just words.
> Anyone reading this is most likely still
> allowed to use tabs.
>
> > "generalizations suck"
>
> Sometimes :)

Mostly agree :-D

Cheers & thanks
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnMnM0ACgkQBcgs9XrR2kakdwCfSPLNgZEWp/2S29oq/CdBp44E
jP4AnA+YvA2Quvk1b6uQgm/t7k/QjV/T
=gSSV
-----END PGP SIGNATURE-----

Emanuel Berg

unread,
Oct 2, 2017, 4:18:30 PM10/2/17
to help-gn...@gnu.org
Kendall Shaw wrote:

>>> I think the OP didn't want to change the
>>> text itself, but just its
>>> display/appearance. So it will look one way
>>> and be another? Why would you do that?
>>
>
> Behold source for a J interpreter:
>
> http://code.jsoftware.com/wiki/Essays/Incunabulum
>
> Sorry for straying from the topic.

OK, good point, but if one doesn't believe in
the technology to begin with, using technology
one believes in to adapt and cope - I've tried
this several times, and *always* failed with
lots of frustration to it. A long time ago, of
course...

It took tons of time, and the result was never
even close to what one could have expected from
the "real/better deal".

Worst part was that all the adapting work felt
completely hopeless because one knew every
single second it was just a totally wasted
effort. So even tho it was programming,
I couldn't enjoy it one bit!

But hey, if you feel like it could work for
you, then don't do it :)

Emanuel Berg

unread,
Oct 2, 2017, 4:18:36 PM10/2/17
to help-gn...@gnu.org
t wrote:

> Those were the folks around Ken Iverson, of
> APL fame.

APL ("A Programming Language" or somtimes
"Array Programming Language") from 1964.

Iverson was the developer so I suppose he
could :)

J (1990) mentioned earlier is a combination of
APL and FP/FL (Functional Programming, 1977;
Function Level 1989) by John Backus.

> I'm certain they could read code
> like that (I can't).

Sure you can, and write it as well, but for how
long before your eyes and head would start to
ache and your whole system communicate "don't
do it" the minute you sit down by the keyboard?

Emanuel Berg

unread,
Oct 2, 2017, 4:18:42 PM10/2/17
to help-gn...@gnu.org
t wrote:

> Well, those were the real wizards.

Write code like that, can't keep it up for
months let alone the time it takes to become
a wizard.

Discontinued algorithm.

Alberto Luaces

unread,
Oct 2, 2017, 4:18:44 PM10/2/17
to help-gn...@gnu.org
Kendall Shaw writes:

> On 09/26/2017 03:14 AM, Emanuel Berg wrote:
>
>> tomás wrote:
>>
>>> I think the OP didn't want to change the text
>>> itself, but just its display/appearance.
>> So it will look one way and be another?
>> Why would you do that?
>>
>
>
> Behold source for a J interpreter:
>
> http://code.jsoftware.com/wiki/Essays/Incunabulum
>
> Sorry for straying from the topic.
>

I feel like I have been slapped in the eyes.

--
Alberto


Emanuel Berg

unread,
Oct 2, 2017, 4:18:49 PM10/2/17
to help-gn...@gnu.org
Kendall Shaw wrote:

> If someone had to interact with others who
> used that style, and if it was not a simple
> matter to force others to accept a different
> code style, one way to live with it might be
> to look for a way to have the code displayed
> in a way that is easier to read, without
> changing the actual text of the code.

Yes, point taken :)

There is just not any pleasure in doing that.
Unless someone has already done it and you can
determine in one second it works well, I for
one wouldn't take it on to begin with.

to...@tuxteam.de

unread,
Oct 2, 2017, 4:18:50 PM10/2/17
to help-gn...@gnu.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well, those were the real wizards.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnM5pMACgkQBcgs9XrR2kbqUQCfaIxqRc3YvaBhYO5Bl771SAm5
RmgAnRyk3+O4Y0FEU3TUxS1Nt55d44Eo
=1eeV
-----END PGP SIGNATURE-----

Emanuel Berg

unread,
Oct 2, 2017, 4:18:51 PM10/2/17
to help-gn...@gnu.org
t wrote:

> I have the hunch that there are some
> fundamental differences between people which
> somehow shine through to what kind of
> language and culture they gravitate to.
> Oversimplified, there are the Java types and
> the Lisp types, or the Python types and the
> Perl types (note that those two last
> languages are pretty similar, which at first
> sight makes this rift the more paradoxical,
> but the language cultures are utterly
> different), or the Eclipse types, the vi
> types and the Emacs types.

I agree Perl and Python are similar to some
degree, Perl is older and more classy tho
(1987 to Python's 1991), Perl being the
original "P" of the LAMP stack.

I have used both Perl and Python but very
little, however not being an OO guy and
detesting the forced indentation of Python
(indentation of course being mandatory still)
I give Perl the upper hand.

For sure, there is no comparing Lisp to Java
they don't even belong in the same sentence,
which is why I made this one intentionally
incorrect.

But, what you call "fundamental differences
between people" I call the old elitism and
snobbism and the fact that there just are
technologies of different caliber - just like
the ice-hockey team of Russia is superior to
England's, and the English rugby team is better
than ditto Russian - and I have no issues with
that whatsoever - perhaps because I myself
always used what was at the top of the pecking
order :)

http://user.it.uu.se/~embe8573/pics/lang.png

> If my hunch is correct, then there's no
> "right" language

There isn't any right or wrong, but there is
a pecking order.

> and religion wars over that are just a waste
> of time.

Religious wars are a "waste of time", but what
isn't, in the end? And can you really waste
time, since doing something else the same
amount of time will waste the same amount of
time? If you enjoy the flame wars, I suppose
that's the reason to do it.

If you care about *the perception* of time
throw the computer into a rock wall and be done
with it.

>> Or well, not exactly like "any" code,
>> because having code like that isn't healthy.
>> It is un-ergonomic for the brain as well as
>> the body.
>
> See? That's where we disagree on. Easy to
> learn isn't always the same as easy to use,

OK? Well, having code look like that will make
it a much bigger effort to deal with and your
fingers/shoulders/eyes/brain, your whole being
will suffer from this for no reason, because
there is no reason for code to look like that.

Eli Zaretskii

unread,
Oct 2, 2017, 4:18:54 PM10/2/17
to help-gn...@gnu.org
> From: Alberto Luaces <alu...@udc.es>
> Date: Tue, 26 Sep 2017 11:12:15 +0200
>
> So, from the top of your head, what would be the less painful method to
> change every comma to a comma+space, or at least change the color of the
> commas to anything more distinguishable and attach it to the language
> mode hook?

Here's one more solution for you to consider, a much simpler one IMO:

(let ((table (or (window-display-table)
buffer-display-table
(make-display-table))))
(aset table ?, (vconcat ", "))
(setq buffer-display-table table))

Kendall Shaw

unread,
Oct 2, 2017, 4:18:56 PM10/2/17
to help-gn...@gnu.org
On 09/28/2017 09:42 AM, Emanuel Berg wrote:

> t wrote:
>
>> Well, those were the real wizards.
> Write code like that, can't keep it up for
> months let alone the time it takes to become
> a wizard.
>
> Discontinued algorithm.

If someone had to interact with others who used that style, and if it
was not a simple matter to force others to accept a different code
style, one way to live with it might be to look for a way to have the
code displayed in a way that is easier to read, without changing the
actual text of the code.

Kendall


to...@tuxteam.de

unread,
Oct 2, 2017, 4:19:02 PM10/2/17
to help-gn...@gnu.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Sep 29, 2017 at 08:42:20AM +0200, Emanuel Berg wrote:

[...]

> > I'm certain they could read code
> > like that (I can't).
>
> Sure you can, and write it as well, but for how
> long before your eyes and head would start to
> ache and your whole system communicate "don't
> do it" the minute you sit down by the keyboard?

I guess I should be more precise, then. I was using "read"
in some "literate" sense, as I would read a text. Wha I'd
do with this kind of code would be more "decipher". I is
a much more deliberate (and painful) process.

My point is that those folks most probably "read" this code
in this more literate way, the way I might, e.g. "read" C
code by R. W. Stevens or Knuth's "METAFONT The Program".

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnN8+UACgkQBcgs9XrR2kZlmwCfZR32ruQcOw3ZJgQRVcs7niwI
4eAAn0tMiLJjoz6sPpkehQNLd4fH7NO0
=t7VG
-----END PGP SIGNATURE-----

Alberto Luaces

unread,
Oct 2, 2017, 4:19:04 PM10/2/17
to help-gn...@gnu.org
Indeed very nice, thank you!

--
Alberto


Emanuel Berg

unread,
Oct 2, 2017, 4:19:10 PM10/2/17
to help-gn...@gnu.org
tomás wrote:

> I guess I should be more precise, then. I was
> using "read" in some "literate" sense, as
> I would read a text. Wha I'd do with this
> kind of code would be more "decipher". I is
> a much more deliberate (and painful) process.

Yes, I understand :) Why do people think
I don't understand all the time? Third time
this thread!

Now yes, at this point it would be decipher but
if you started using that language it would be
reading and writing like any code.

Or well, not exactly like "any" code, because
having code like that isn't healthy. It is
un-ergonomic for the brain as well as the body.

to...@tuxteam.de

unread,
Oct 2, 2017, 4:19:14 PM10/2/17
to help-gn...@gnu.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Sep 29, 2017 at 12:16:04PM +0200, Emanuel Berg wrote:
> tomás wrote:
>
> > I guess I should be more precise, then. I was
> > using "read" in some "literate" sense, as
> > I would read a text. Wha I'd do with this
> > kind of code would be more "decipher". I is
> > a much more deliberate (and painful) process.
>
> Yes, I understand :) Why do people think
> I don't understand all the time? Third time
> this thread!
>
> Now yes, at this point it would be decipher but
> if you started using that language it would be
> reading and writing like any code.

After some period of training. Perhaps. But then... perhaps
not. This is one point where we might differ. I have the hunch
that there are some fundamental differences between people which
somehow shine through to what kind of language and culture they
gravitate to. Oversimplified, there are the Java types and the
Lisp types, or the Python types and the Perl types (note that
those two last languages are pretty similar, which at first
sight makes this rift the more paradoxical, but the language
cultures are utterly different), or the Eclipse types, the vi
types and the Emacs types.

If my hunch is correct, then there's no "right" language and
religion wars over that are just a waste of time. Get along and
be nice to each other and ponies and flowers and all that. And
keep in mind that saying "one must not write programs in C" [1],
to some, sounds like "you don't exist", which is a terrible
insult.

> Or well, not exactly like "any" code, because
> having code like that isn't healthy. It is
> un-ergonomic for the brain as well as the body.

See? That's where we disagree on. Easy to learn isn't always the
same as easy to use, And then (my hunch, at least), for whom.

Cheers

[1] "C", dear reader, should be read as a placeholder, of course.
What did you think?
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnOIa4ACgkQBcgs9XrR2kbGkwCfUiti9ijYCaf2hd5yB2WCT6NA
TycAnApj7GnOkCzhTS2uRlA6CtAwYOCf
=X0RC
-----END PGP SIGNATURE-----

Kendall Shaw

unread,
Oct 2, 2017, 4:23:12 PM10/2/17
to help-gn...@gnu.org
On 09/26/2017 03:14 AM, Emanuel Berg wrote:

> tomás wrote:
>

James K. Lowden

unread,
Oct 2, 2017, 9:57:24 PM10/2/17
to
On Wed, 27 Sep 2017 14:07:41 +0200
<to...@tuxteam.de> wrote:

> I think last time around I tried to make my point to Emanuel with
> the sentence "generalizations suck" or some such.

Well, as I'm sure you know:

All generalizations are false.

:-)

--jkl

Emanuel Berg

unread,
Oct 2, 2017, 10:49:55 PM10/2/17
to help-gn...@gnu.org
James K. Lowden wrote:

> Well, as I'm sure you know:
>
> All generalizations are false.
>
> :-)

It seems, after many years doing this,
discussion has finally reached school-boy
level! How about this one?

cats exist
to show
that not everything
has to have a function

Pretty good, ey? :)

Here is another interesting school-boy problem.
The result is 12.6 cm which seems reasonable.

;; if you are making a grid
;; out of beams
;; that are of different sizes
;; it doesn't look asymmetric
;; if you make the *holes* equally big!

(defun compute-wood-distance (total beams)
(let*((sum-beam (apply #'+ beams) )
(space (- total sum-beam))
(num-holes (1+ (length beams)))
(hole-len (/ space num-holes)) )
(message "%.1f cm" hole-len) ))

;; (compute-wood-distance 139 '(6 7 9.5 9.5 9.5 9.5)) ;; 12.6 cm
0 new messages