Long file names in Dired

[Marcin Borkowski]

Hi all,

so I have some really, really long filenames (say, more than 70
characters), and I'd like to shorten them so they don't spill to the
next line in Dired. I can toggle-truncate-lines, of course, but then
I don't see the extension, and I'd prefer to truncate the part /before/
the extension.

Is there any Dired hack enabling this? If not, where i should tinker to
achieve that? Would making some parts of the text invisible be a good
way to do that? If yes, is there any Dired hook I could use for that?

BTW, the /reason/ I have long filenames is that I have a bunch of pdfs
with scientific articles, and I decided that putting the author names,
publication year and a ttile (at least shortened) into the filename
might be a good idea so that I don't get lost. An alternative would be
e.g. an Org-mode based database with links to files, but then relocating
them would be non-trivial.

TIA,

--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

[Bob Proulx]

Marcin Borkowski wrote:
> so I have some really, really long filenames (say, more than 70
> characters), and I'd like to shorten them so they don't spill to the
> next line in Dired. I can toggle-truncate-lines, of course,

That was the first thing I thought of too.

> but then I don't see the extension, and I'd prefer to truncate the
> part /before/ the extension.

Explain more? The file extension isn't special to toggle-truncate-lines.

> Is there any Dired hack enabling this?

Have you used C-x < and C-x > scroll-left and scroll-right from the
horizontal scrolling section?

https://www.gnu.org/software/emacs/manual/html_node/emacs/Horizontal-Scrolling.html

Then scroll so that the extensions are visible? As long as the
beginning of the file name is in the visible window then everything
works okay for me. Does that work for you?

Bob

[Emanuel Berg]

Marcin Borkowski <mb...@mbork.pl> writes:

> BTW, the reason I have long filenames is that I have

> a bunch of pdfs with scientific articles, and
> I decided that putting the author names, publication
> year and a ttile (at least shortened) into the
> filename might be a good idea so that I don't get
> lost. An alternative would be e.g. an Org-mode based
> database with links to files, but then relocating
> them would be non-trivial.

This idea is even better - use BibTeX. In a .bib file,
write entries like this - every book, article, paper,
etc. you read, you make an entry:

@book{cpp,
author = {Bjarne Stroustrup},
title = {The C++ Programming Language},
edition = {Second Edition},
publisher = {Addison-Wesley},
year = 1992,
ISBN = {0-201-53992-6}
}

In LaTeX, a reference is made with \cite, e.g.:

C++ is an extension of C, which is the system
programming language of choice since the early-mid
70s. \cite[pp. v-vi, 6, 41-42]{cpp}

Then rename the file: cpp.pdf

If you use Emacs to view PDFs as well, for the .bib
file (the BibTeX mode), write a defun that takes the
entry-around-point's name ('cpp' in this case) and
combines it with the path where you have the PDF (all
of them), and suddenly you are only the extention away
from having an as-is text-editable menu to browse all
that stuff as well.

Don't thank me. I'll send an invoice :)

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

[Eli Zaretskii]

> From: Marcin Borkowski <mb...@mbork.pl>
> Date: Fri, 24 Apr 2015 01:10:24 +0200

>
> so I have some really, really long filenames (say, more than 70
> characters), and I'd like to shorten them so they don't spill to the

> next line in Dired. I can toggle-truncate-lines, of course, but then

> I don't see the extension, and I'd prefer to truncate the part /before/
> the extension.
>

> Is there any Dired hack enabling this?

Not that I know of (but others might, so don't consider that as a
definitive answer).

One obvious way to show long file names is to have wider
frames/windows.

Failing that, I think we will welcome a patch that shortens file names
in Dired intelligently, basically displaying something like
foo...bar.ext, with the place of the ellipsis strategically computed
to show as much of the file name as possible, including the extension.

If you, or someone else, decide to work on that, beware of the fact
that Dired puts a special text property on the file name, which is
needed for correct operation of Dired commands when the file names
include special characters, like whitespace. You should be careful
not to destroy this subtle feature.

[Marcin Borkowski]

On 2015-04-24, at 03:26, Emanuel Berg <embe...@student.uu.se> wrote:

> Marcin Borkowski <mb...@mbork.pl> writes:
>
>> BTW, the reason I have long filenames is that I have
>> a bunch of pdfs with scientific articles, and
>> I decided that putting the author names, publication
>> year and a ttile (at least shortened) into the
>> filename might be a good idea so that I don't get
>> lost. An alternative would be e.g. an Org-mode based
>> database with links to files, but then relocating
>> them would be non-trivial.
>
> This idea is even better - use BibTeX. In a .bib file,

I. HATE. BIBTEX. WITH. A. PASSION.

(And I have reasons - basically, BibTeX is a pile of crap. I agree that
it /is/ less unusable for writing in English exclusively, but again - it
creates /a lot/ more problems than it solves.)

That said, I like that idea, though I would use BibLaTeX (which is
a modern replacement for BibTeX, curing many - even though not all - of
its problems (the main one which it doesn't help is the format for
multiple authors), or amsrefs, which is less powerful than Bib(La)TeX,
but has a much saner format for multiple names (and is /way/ easier to
configure than Bib(La)TeX).

> write entries like this - every book, article, paper,
> etc. you read, you make an entry:
>
> @book{cpp,
> author = {Bjarne Stroustrup},
> title = {The C++ Programming Language},
> edition = {Second Edition},
> publisher = {Addison-Wesley},
> year = 1992,
> ISBN = {0-201-53992-6}
> }
>
> In LaTeX, a reference is made with \cite, e.g.:
>
> C++ is an extension of C, which is the system
> programming language of choice since the early-mid
> 70s. \cite[pp. v-vi, 6, 41-42]{cpp}
>
> Then rename the file: cpp.pdf
>
> If you use Emacs to view PDFs as well, for the .bib
> file (the BibTeX mode), write a defun that takes the
> entry-around-point's name ('cpp' in this case) and
> combines it with the path where you have the PDF (all
> of them), and suddenly you are only the extention away
> from having an as-is text-editable menu to browse all
> that stuff as well.
>
> Don't thank me. I'll send an invoice :)

Haha. But thanks, I like this idea. (Though using Org-mode properties
might be even better than using Bib(La)TeX or amsrefs etc.)

Thanks a lot!

[Rasmus]

Hi,

Marcin Borkowski <mb...@mbork.pl> writes:

>> This idea is even better - use BibTeX. In a .bib file,
>

> I. HATE. BIBTEX. WITH. A. PASSION.

> [...]

I find the format OK. I can't imagine a vastly superior format for
metadata...

> That said, I like that idea, though I would use BibLaTeX (which is
> a modern replacement for BibTeX, curing many - even though not all - of
> its problems (the main one which it doesn't help is the format for
> multiple authors), or amsrefs, which is less powerful than Bib(La)TeX,
> but has a much saner format for multiple names (and is /way/ easier to
> configure than Bib(La)TeX).

I organize articles like

~/documents/literature/FirstAuthorYear[UniqueSuffixAsNecessary]

E.g.

~/documents/literature/smith88/smith88.bib
~/documents/literature/smith88/smith88.pdf
~/documents/literature/smith88/smith88_data.zip
~/documents/literature/smith88/smith88_notes.org

I then create

~/documents/literature/lit.bib

which is is a concatenation of all *.bib files in subfolders as well as a
special file, various.bib, which holds entries I don't want to maintain.

In addition, I generate lit.{org,html} which summarizes of all metadata
and notes with links to pdfs.

Cheers,
Rasmus

--
If you can mix business and politics wonderful things can happen!

[Marcin Borkowski]

On 2015-04-24, at 11:12, Rasmus <ras...@gmx.us> wrote:

> Hi,
>
> Marcin Borkowski <mb...@mbork.pl> writes:
>

>>> This idea is even better - use BibTeX. In a .bib file,
>>

>> I. HATE. BIBTEX. WITH. A. PASSION.
>> [...]
>
> I find the format OK. I can't imagine a vastly superior format for
> metadata...

1. Multiple authors are separated with the five-character string
" and ". Can you imagine a more stupid idea? What if you want to quote
an anonymous report whose author field should say "National Aeronautics
and Space Administration"? Yes, you /can/ quote the " and ", but this
shouldn't be even needed.

2. BibTeX separates the author name into (at most) four components,
called "first", "last", "von" and "jr". No support for: Chinese names
(not fitting into this format) and names in some other languages (I'm
forgetting now which ones).

3. What about alphabetic sorting in various languages?

4. Since BibTeX is aimed (after all) at a typesetting system, what about
diferent hyphenation patterns? Imagine an article written in Polish,
citing a paper by a German (so the name should be hyphenated differently
than the rest of the document), the paper being in English, and
published by an Italian university. Where's support for that (i.e.,
language field for the author, title etc.)? (Not to mention several
authors from various langauge backgrounds.)

5. What about all these funny characters not found in English, and in
particular sorting using them? (See the docs for the xindy indexing
tool for examples of nontrivial problems regarding locale-aware
sorting.)

6. What about custom citation styles? Have you seen the syntax of the
bst files? If yes, you know the pain, and if not, you'd better not look
at them, for your own good...

7. BibTeX is not really "case-sensitive" or "case-insensitive", it's
"case-destroying". IOW, /you have to quote capital letters in titles/
so that BibTeX doesn't convert them to lowercase.

BTW, BibLaTeX addresses (AFAIK) problems 3, 5, 6 and 7. The amsrefs
package addresses problems 1, 2, 4, 6 and 7.

> I organize articles like
>
> ~/documents/literature/FirstAuthorYear[UniqueSuffixAsNecessary]
>
> E.g.
>
> ~/documents/literature/smith88/smith88.bib
> ~/documents/literature/smith88/smith88.pdf
> ~/documents/literature/smith88/smith88_data.zip
> ~/documents/literature/smith88/smith88_notes.org
>
> I then create
>
> ~/documents/literature/lit.bib
>
> which is is a concatenation of all *.bib files in subfolders as well as a
> special file, various.bib, which holds entries I don't want to maintain.
>
> In addition, I generate lit.{org,html} which summarizes of all metadata
> and notes with links to pdfs.

Again: nice, and thanks for the tips. But still, BibTeX is a wrong tool
for that. (As you might guess, IMHO BibTeX is a wrong tool for
/anything/.)

Note that no BibTeX based solution helps /if I want to be able to move
files between directories/. (Though I might arrange my system so that
I don't have to do that - it's part of my current workflow, but not an
indispensable one.)

> Cheers,
> Rasmus

Best,

[Rasmus]

Marcin Borkowski <mb...@mbork.pl> writes:

>>> I. HATE. BIBTEX. WITH. A. PASSION.
>>> [...]
>>
>> I find the format OK. I can't imagine a vastly superior format for
>> metadata...
>
> 1. Multiple authors are separated with the five-character string
> " and ".

I type quickly enough for this not to bother me. Perhaps ";" would be
better, but for the sake of comparability I can live with " and ". OTOH
it may make human parsing more easy when reading the bib file.

> Can you imagine a more stupid idea? What if you want to quote
> an anonymous report whose author field should say "National Aeronautics
> and Space Administration"? Yes, you /can/ quote the " and ", but this
> shouldn't be even needed.

Author = {{National Aeronautics and Space Administration}}

> 2. BibTeX separates the author name into (at most) four components,
> called "first", "last", "von" and "jr". No support for: Chinese names

> (not fitting into this format)e and names in some other languages (I'm
> forgetting now which ones).

Another flaw is the auto-guessing of names e.g. for three names one must
use "last, first middle" vs "first last" or "last, first" for two names.

> 3. What about alphabetic sorting in various languages?

This is orthogonal to the format. I believe Biber reads unicode.

> 4. Since BibTeX is aimed (after all) at a typesetting system, what about
> diferent hyphenation patterns? Imagine an article written in Polish,
> citing a paper by a German (so the name should be hyphenated differently
> than the rest of the document), the paper being in English, and
> published by an Italian university. Where's support for that (i.e.,
> language field for the author, title etc.)?

Biblatex will read language field. I don't know how it uses it. In any
case, that's orthogonal to the bibtex format as a "database".

> (Not to mention several authors from various langauge backgrounds.)

If there's a name you can't type, I guess it's the fault of unicode.

> 5. What about all these funny characters not found in English, and in
> particular sorting using them? (See the docs for the xindy indexing
> tool for examples of nontrivial problems regarding locale-aware
> sorting.)

This is a flaw with the bibtex program. Biber is better.

BTW: Emacs 24 can't do local-aware sorting (but string-collate-lessp is in
25). This would suggest to me that it's a nontrivial problem.

> 6. What about custom citation styles? Have you seen the syntax of the
> bst files? If yes, you know the pain, and if not, you'd better not look
> at them, for your own good...

Yes. I used to use custombib or whatever it was called to generate bst
files. Pain.

Again, this is orthogonal to the bibtex file-format.

> 7. BibTeX is not really "case-sensitive" or "case-insensitive", it's
> "case-destroying". IOW, /you have to quote capital letters in titles/
> so that BibTeX doesn't convert them to lowercase.

I think you can use: {{}}.

> BTW, BibLaTeX addresses (AFAIK) problems 3, 5, 6 and 7.

Would 3 not be biber? For 4 perhaps you can use the langid field (pp. 24
in the "texdoc biblatex" in TL14). I don't know if it's as extensive as
you need.

> The amsrefs package addresses problems 1, 2, 4, 6 and 7.

I don't know it. The AMS math packages are good quality.

> Again: nice, and thanks for the tips. But still, BibTeX is a wrong tool
> for that.

I'm using the *format*, not the binary "bibtex". Biber is good, and via
reftex Emacs has good support for the bibtex format.

> Note that no BibTeX based solution helps /if I want to be able to move
> files between directories/.

In the above system you'd move *folders* rather than files. An entry is a
container (folder) of:

{metadata, article, notes, data/program}

You could have that in a single file (tar), but why bother?

—Rasmus

--
And when I’m finished thinking, I have to die a lot

[Marcin Borkowski]

On 2015-04-24, at 12:19, Rasmus <ras...@gmx.us> wrote:

> Marcin Borkowski <mb...@mbork.pl> writes:
>
>>>> I. HATE. BIBTEX. WITH. A. PASSION.
>>>> [...]
>>>
>>> I find the format OK. I can't imagine a vastly superior format for
>>> metadata...
>>
>> 1. Multiple authors are separated with the five-character string
>> " and ".
>
> I type quickly enough for this not to bother me. Perhaps ";" would be
> better, but for the sake of comparability I can live with " and ". OTOH
> it may make human parsing more easy when reading the bib file.

It's not about typing. It's about the stupidity of the format itself
(see below).

>> Can you imagine a more stupid idea? What if you want to quote
>> an anonymous report whose author field should say "National Aeronautics
>> and Space Administration"? Yes, you /can/ quote the " and ", but this
>> shouldn't be even needed.
>
> Author = {{National Aeronautics and Space Administration}}

I know. But see above and below. Why not use amsref's approach of
"repeatable fields"?

>> 2. BibTeX separates the author name into (at most) four components,
>> called "first", "last", "von" and "jr". No support for: Chinese names
>> (not fitting into this format)e and names in some other languages (I'm
>> forgetting now which ones).
>
> Another flaw is the auto-guessing of names e.g. for three names one must
> use "last, first middle" vs "first last" or "last, first" for two names.
>
>> 3. What about alphabetic sorting in various languages?
>
> This is orthogonal to the format. I believe Biber reads unicode.

Fair enough.

>> 4. Since BibTeX is aimed (after all) at a typesetting system, what about
>> diferent hyphenation patterns? Imagine an article written in Polish,
>> citing a paper by a German (so the name should be hyphenated differently
>> than the rest of the document), the paper being in English, and
>> published by an Italian university. Where's support for that (i.e.,
>> language field for the author, title etc.)?
>
> Biblatex will read language field. I don't know how it uses it. In any
> case, that's orthogonal to the bibtex format as a "database".

No, it's not. As I hinted above, what's really needed is a language
"field" for /any other field/, separately. One "language" field per
/entry/ is not enough.

>> (Not to mention several authors from various langauge backgrounds.)
>
> If there's a name you can't type, I guess it's the fault of unicode.

See above. Due to the idiocy of the " and " approach, even if there
were a method of declaring different languages for different fields, it
wouldn't help here. This is not about scripts, but about
e.g. hyphenation patterns (which are language-dependent), or decomposing
names into parts (which BibTeX /the program/ can't do correctly anyway,
and the format doesn't help a lot, either).

>> 5. What about all these funny characters not found in English, and in
>> particular sorting using them? (See the docs for the xindy indexing
>> tool for examples of nontrivial problems regarding locale-aware
>> sorting.)
>
> This is a flaw with the bibtex program. Biber is better.

Of course, you're right here.

> BTW: Emacs 24 can't do local-aware sorting (but string-collate-lessp is in
> 25). This would suggest to me that it's a nontrivial problem.

Yes, it /is/ nontrivial. (See xindy's docs for real-life examples.)

>> 6. What about custom citation styles? Have you seen the syntax of the
>> bst files? If yes, you know the pain, and if not, you'd better not look
>> at them, for your own good...
>
> Yes. I used to use custombib or whatever it was called to generate bst
> files. Pain.
>
> Again, this is orthogonal to the bibtex file-format.

Again, you're right here.

>> 7. BibTeX is not really "case-sensitive" or "case-insensitive", it's
>> "case-destroying". IOW, /you have to quote capital letters in titles/
>> so that BibTeX doesn't convert them to lowercase.
>
> I think you can use: {{}}.

Yes, but /why/ should the user be enforced to do /that/?

>> BTW, BibLaTeX addresses (AFAIK) problems 3, 5, 6 and 7.
>
> Would 3 not be biber? For 4 perhaps you can use the langid field (pp. 24
> in the "texdoc biblatex" in TL14). I don't know if it's as extensive as
> you need.

By "BibLaTeX" I mean the whole thing - the LaTeX package /and/ Biber.

>> The amsrefs package addresses problems 1, 2, 4, 6 and 7.
>
> I don't know it. The AMS math packages are good quality.

Yes, at least from the user's perspective - reading their code can
sometimes reveal some funny skeletons in the closet;-).

>> Again: nice, and thanks for the tips. But still, BibTeX is a wrong tool
>> for that.
>
> I'm using the *format*, not the binary "bibtex". Biber is good, and via
> reftex Emacs has good support for the bibtex format.

So I heard. It's a pity that reftex doesn't support amsrefs. (I'm
considering helping to remedy this situation.)

>> Note that no BibTeX based solution helps /if I want to be able to move
>> files between directories/.
>
> In the above system you'd move *folders* rather than files. An entry is a
> container (folder) of:

So it's even worse. What I want is the ability to e.g. simply move the
pdf from the directory "to-read" to the directory
"articles-on-fixed-points".

> —Rasmus

Best,

[Marcin Borkowski]

On 2015-04-24, at 23:02, Marcin Borkowski <mb...@mbork.pl> wrote:

> See above. Due to the idiocy of the " and " approach, even if there
> were a method of declaring different languages for different fields, it
> wouldn't help here. This is not about scripts, but about
> e.g. hyphenation patterns (which are language-dependent), or decomposing
> names into parts (which BibTeX /the program/ can't do correctly anyway,
> and the format doesn't help a lot, either).

Oh, and I found the discussion I wanted to link here (it's on the
ConTeXt mailing list, and it shows how nontrivial the "name decomposing"
thing is /even for European languages/, which many (mistakenly) consider
"simple"):

http://www.ntg.nl/pipermail/ntg-context/2015/080687.html

Again, BibTeX (both the format and the program) just butchers
non-English names, and doesn't care. (I'm not sure about the
BibLaTeX+Biber combo, but I'm afraid that it's similar.) I guess it
/is/ possible to overcome this with some quoting (or "bracing";-)), but
still: the "First, von, Last, jr" model is just too simplistic.

Best,

[Emanuel Berg]

Marcin Borkowski <mb...@mbork.pl> writes:

> (And I have reasons - basically, BibTeX is a pile of
> crap. I agree that it /is/ less unusable for writing
> in English exclusively, but again - it creates /a
> lot/ more problems than it solves.)

You mean you write in Polish at your universities?

(Not to say LaTeX, BibTeX, etc. cannot be used outside
them walls of science, of course: I always said if
writers learned LaTeX - and some HTML and CSS for PR -
they would put the entire publishing industry out
of business.)

> That said, I like that idea, though I would use
> BibLaTeX (which is a modern replacement for BibTeX,
> curing many - even though not all - of its problems
> (the main one which it doesn't help is the format
> for multiple authors), or amsrefs, which is less
> powerful than Bib(La)TeX, but has a much saner
> format for multiple names (and is /way/ easier to
> configure than Bib(La)TeX).

I have no experience with amsrefs. I am unsure if
I use BibTeX or BibLaTeX.

This is the part of the Makefile that does the .bib
file:

biber -q ${name} # get .bbl (from .bcf)

And this is the line in the .tex file:

\usepackage[backend=biber]{biblatex}

So when I said BibTex, probably that should
be BibLaTeX!

As for the problem with multiple authors, I haven't
came across that. I have many entries of the kind:

@techreport{scheduling-of-mixed-criticality-applications,
author = {Georgia Giannopoulou and Nikolay Stoimenov and Pengcheng Huang and Lothar Thiele},
title = {Scheduling of Mixed-Criticality Applications on Resource-Sharing Multicore Systems},
institution = {Computer Engineering and Networks Laboratory, ETH Zurich, 8092 Zurich, Switzerland},
year = 2013
}

You mean the problem is, that turns out as "et. al."
in the PDF? I'm sure that can be configured if you
have a problem with it. I don't, and besides no one
care for references anyway - just put them there and
then forget about them, is what people do.

[Marcin Borkowski]

On 2015-04-25, at 03:29, Emanuel Berg <embe...@student.uu.se> wrote:

> Marcin Borkowski <mb...@mbork.pl> writes:
>
>> (And I have reasons - basically, BibTeX is a pile of
>> crap. I agree that it /is/ less unusable for writing
>> in English exclusively, but again - it creates /a
>> lot/ more problems than it solves.)
>
> You mean you write in Polish at your universities?

Of course we do, sometimes. Textbooks/lecture notes, for instance. And
articles on (non-mathematical) stuff which is relevant only for Poland
anyway. (Like research on the changing syllabi of school subjects in
Poland.)

> (Not to say LaTeX, BibTeX, etc. cannot be used outside
> them walls of science, of course: I always said if
> writers learned LaTeX - and some HTML and CSS for PR -
> they would put the entire publishing industry out
> of business.)

And - as you point out - LaTeX is not exclusive to academia. Though
I don't agree with you about the publishing industry: authors usually
suck at typography, and they usually don't care anyway.

>> That said, I like that idea, though I would use
>> BibLaTeX (which is a modern replacement for BibTeX,
>> curing many - even though not all - of its problems
>> (the main one which it doesn't help is the format
>> for multiple authors), or amsrefs, which is less
>> powerful than Bib(La)TeX, but has a much saner
>> format for multiple names (and is /way/ easier to
>> configure than Bib(La)TeX).
>
> I have no experience with amsrefs. I am unsure if
> I use BibTeX or BibLaTeX.
>
> This is the part of the Makefile that does the .bib
> file:
>
> biber -q ${name} # get .bbl (from .bcf)
>
> And this is the line in the .tex file:
>
> \usepackage[backend=biber]{biblatex}
>
> So when I said BibTex, probably that should
> be BibLaTeX!

Yes.

> As for the problem with multiple authors, I haven't
> came across that. I have many entries of the kind:
>
> @techreport{scheduling-of-mixed-criticality-applications,
> author = {Georgia Giannopoulou and Nikolay Stoimenov and Pengcheng Huang and Lothar Thiele},
> title = {Scheduling of Mixed-Criticality Applications on Resource-Sharing Multicore Systems},
> institution = {Computer Engineering and Networks Laboratory, ETH Zurich, 8092 Zurich, Switzerland},
> year = 2013
> }
>
> You mean the problem is, that turns out as "et. al."
> in the PDF? I'm sure that can be configured if you
> have a problem with it. I don't, and besides no one
> care for references anyway - just put them there and
> then forget about them, is what people do.

No. The problem is that if LaTeX happens to hyphenate the author's
name, or the publisher's name, or the title, or the university name,
etc. (which is quite possible), it should do it according to the rules
for the language of that particular field. The amsrefs package is the
only tool I know of that supports setting the language independently for
each field. And with BibTeX's author syntax it would be rather awkward
to implement.

(Another thing - as I mentioned - is that that whole first/von/last/jr
stuff is quite English-centered. In non-Germanic languages this is
sometimes completely irrelevant - take Russian with its "patronimicum",
which is similar to the middle name, but is someting else (it's
basically things like "John, son of Jack, Smith). In Polish, we don't
have "von", and using "jr" is very rare, though possible, but seems (at
least to me) extremely pretentious. Or take Icelandic, where the name
structure is totally different than in other languages - many Icelanders
/don't ebven have/ the family name (and they sort their names by the
first name!). Or - as was discussed in the exchange I linked to -
German "von" and Dutch "van" are semantically (and typographically)
different. Or take some Asian languages, where the order of the first
and last names is inverted.)

And there are quite a few people who /do/ care about the references.
For instance, I work for a journal, where we (with a friend of mine) are
responsible for (among others) typesetting the papers. We sometimes
spend/waste quite a lot of time on bibliographies (mainly because
authors "don't care" - if they actually used BibTeX and not
hand-crafted, inconsistent formatting, things would be a lot easier for
us...). I even wrote an Emacs utility which helps transform such
inconsistent pile of s##t into proper markup.

Best,

[Emanuel Berg]

Marcin Borkowski <mb...@mbork.pl> writes:

> Though I don't agree with you about the publishing
> industry: authors usually suck at typography, and
> they usually don't care anyway.

It is just something they never did. I child can learn
it. I don't know what the publishing houses do all
day. Typesetting in LaTeX (or even old-school groff
which is what I think O'Reilly uses) isn't easy first
day but after a while you understand how it works.
Then, after you get the details the way you want it is
is only a matter of using 99% of the same over and
over. So it should have been standardized one zillion
times over by now.

> The problem is that if LaTeX happens to hyphenate
> the author's name, or the publisher's name, or the
> title, or the university name, etc. (which is quite
> possible), it should do it according to the rules
> for the language of that particular field.

Is that why you hate BibLaTeX? ... :J

Did you consider disabling hyphenation altogether?

> (Another thing - as I mentioned - is that that whole
> first/von/last/jr stuff is quite English-centered.
> In non-Germanic languages this is sometimes
> completely irrelevant - take Russian with its
> "patronimicum", which is similar to the middle name,
> but is someting else (it's basically things like
> "John, son of Jack, Smith).

Yes. In Sweden we instead have that "incorporated" in
the last name, often: Svensson, Bengtsson, ...
(literally Sven's son, Bengt's son, etc., but they are
just family names: the father isn't for this reason
Sven and Bengt as with the Russian system).

> In Polish, we don't have "von"

Why - did the communists wipe out the entire Polish
nobility? Alright. This is interesting, but what does
it have to do with BibLaTeX?

> and using "jr" is very rare, though possible, but
> seems (at least to me) extremely pretentious.

It can also be functional, to separate the two persons
with the same name. For example, the famous American
and Mexican boxers - fathers and sons:

Floyd Mayweather Sr./Jr.
Julio César Chávez Sr./Jr.

> Or take Icelandic, where the name structure is
> totally different than in other languages - many

> Icelanders /don't even have/ the family name (and

> they sort their names by the first name!).

What does it matter what exceptional and goofy
convention some people have somewhere around the
world? The do have *names* on Iceland. A BibLaTeX
entry has an author field. Just type the name of the
the industrious Icelander there!

> And there are quite a few people who /do/ care about
> the references. For instance, I work for a journal,
> where we (with a friend of mine) are responsible for
> (among others) typesetting the papers. We sometimes
> spend/waste quite a lot of time on bibliographies
> (mainly because authors "don't care" - if they
> actually used BibTeX and not hand-crafted,
> inconsistent formatting, things would be a lot
> easier for us...). I even wrote an Emacs utility
> which helps transform such inconsistent pile of s##t
> into proper markup.

Of course references should be correct and consistent
and software (including Emacs modes) should support
it. I think BibLaTeX does its job and the problem (?)
with lack of support for "national hyphenation" isn't
anything I would ever worry about.

[Marcin Borkowski]

Hi, Emanuel!

(Disclaimer: I tried not to sound rude in my email. If I failed, please
take into consideration that this was not my intent! I just strongly
disagree with most of what you wrote.)

On 2015-04-25, at 13:20, Emanuel Berg <embe...@student.uu.se> wrote:

> Marcin Borkowski <mb...@mbork.pl> writes:
>
>> Though I don't agree with you about the publishing
>> industry: authors usually suck at typography, and
>> they usually don't care anyway.
>
> It is just something they never did. I child can learn
> it. I don't know what the publishing houses do all
> day. Typesetting in LaTeX (or even old-school groff

Wow, this seems to cross the boundary of trolling. ;-)

Have you read Bringhurst ("The Elements of Typographic Style")? Or
Tschichold ("Die neue Typographie")? (Not that I agree with him, btw.)
Or Hochuli ("Das Detail in der Typografie")?

If by "typography" you mean "putting all the elements where the designer
wants them to be" - then I agree (to some extent - try using LaTeX to
typeset anything containing equations /and/ figures on the grid, or to
wrap a figure with text when the text includes an enumeration - good
luck!) that it's /relatively/ simple (at least most of the time).

If by "typography" you mean "the art and technique of arranging type to
make written language readable and appealing" (this is what Wikipedia
has), then you most probably need /at least/ half a dozen years to get
reasonable experience, and twice to three times that to achive what
could be called mastery.

If you're wondering what the publishing houses do all day, I can tell
you what. I work for a small journal (two issues per year, each issue
is typically 150-200 pages long), and it's /a lot/ of work. I work
there with a friend, and our duties are (mainly) to, let's call it,
"make the issue look good". We receive the files prepared by the
authors, and after several weeks of hard work we produce a pdf file
ready to send to the printing house. And by hard work I mean hard work
- probably the main reason it's just "hard" and not "impossible" is
several thousand hours of experience of both of us. (Another reason is
that I have a few hundred lines of Elisp code, automating these parts of
our job that /can/ be automated - it's not even a majority, but it saves
us considerable time of boring, repetitive tasks.)

> which is what I think O'Reilly uses) isn't easy first
> day but after a while you understand how it works.

Well, I don't know groff, but the subtle interactions of the
line-breaking and page-breaking algorithms in TeX, for instance, or
positioning of floats, are not something you would understand after
a "while". (I have about 20 years of experience with TeX and LaTeX,
both high and low level, and now and again I'm totally astonished and
can't fathom what happened to some page or footnote or figure.)

> Then, after you get the details the way you want it is
> is only a matter of using 99% of the same over and
> over. So it should have been standardized one zillion
> times over by now.

Yeah, it should have been. Now how do you explain how it's possible
that such a "trivial" issue - putting a bunch of smaller rectangular
things on one big rectangular thing - cannot be solved satisfactorily,
even though it's 2015? (I'm looking at you, CSS!)

>> The problem is that if LaTeX happens to hyphenate
>> the author's name, or the publisher's name, or the
>> title, or the university name, etc. (which is quite
>> possible), it should do it according to the rules
>> for the language of that particular field.
>
> Is that why you hate BibLaTeX? ... :J

One of the reasons. I explained the other ones earlier.

> Did you consider disabling hyphenation altogether?

Doesn't make sense - it will lead to disastrous results. What's more,
it /should not be needed/ - this is a trivial programming problem which
should be /solved/ by standard tools. (Well, hyphenating itself is not
a /trivial/ problem, but it's more or less /solved/ - though it might be
interesting for some of you to learn that TeX's hyphenating algorithm,
and the process of preparing the patterns for that algorithm, were the
basis in a PhD in CS.)

>> (Another thing - as I mentioned - is that that whole
>> first/von/last/jr stuff is quite English-centered.
>> In non-Germanic languages this is sometimes
>> completely irrelevant - take Russian with its
>> "patronimicum", which is similar to the middle name,
>> but is someting else (it's basically things like
>> "John, son of Jack, Smith).
>
> Yes. In Sweden we instead have that "incorporated" in
> the last name, often: Svensson, Bengtsson, ...
> (literally Sven's son, Bengt's son, etc., but they are
> just family names: the father isn't for this reason
> Sven and Bengt as with the Russian system).

I see. We have some similar names in Polish, too, but they are also
just family names nowadays.

>> In Polish, we don't have "von"
>
> Why - did the communists wipe out the entire Polish
> nobility? Alright. This is interesting, but what does
> it have to do with BibLaTeX?

Well, not exactly - it's just that the nobility doesn't count anymore.
(And yes, the communists helped that process a lot, as well as Germans
during WW2.)

What does it have to do with BibLaTeX? Exactly what I wrote about:
different countries (or cultures) have different naming schemes, and
BibLaTeX supports only a small subset of the set of Germanic naming
schemes. No Slavic ones (granted, the Polish one is trivial, especially
now that it's simplified: even though we don't have any von-like thing,
we did have declension of names depending on sex, and for female names
also on the marital status: the wife of Mr. Nowak used to be called
Nowakowa, and his daughter - Nowakówna. These forms, however, are very
seldom used now. AFAIK, in Czech you still have something like this),
no Asian ones, no Icelandic ones. (I don't know about other languages.)

>> and using "jr" is very rare, though possible, but
>> seems (at least to me) extremely pretentious.
>
> It can also be functional, to separate the two persons
> with the same name. For example, the famous American
> and Mexican boxers - fathers and sons:
>
> Floyd Mayweather Sr./Jr.
> Julio César Chávez Sr./Jr.

Of course, but here in Poland we seldom give the son the same name as
his father's. (And I would argue that doing that might be seen as
pretentious, too.) Apart from the so-called "celebrities", I know
exactly one (rather eccentric, btw) person who actually did it, and even
though he's Polish, he lives in the US, where it's apparently more
common.

>> Or take Icelandic, where the name structure is
>> totally different than in other languages - many
>> Icelanders /don't even have/ the family name (and
>> they sort their names by the first name!).
>
> What does it matter what exceptional and goofy
> convention some people have somewhere around the
> world? The do have *names* on Iceland. A BibLaTeX
> entry has an author field. Just type the name of the
> the industrious Icelander there!

Not exactly. A BibLaTeX entry has an author field, which should contain
the last, prefix, first and postfix parts, some separated by commas and
some by spaces, in a strictly defined (and a bit counterintuitive)
order. Assume that you're an Icelander writing an article in Icelandic,
with a bibliography of works by Icelandic authors. Assume that you want
them sorted by the first name (apparently, this is what Icelanders do).
How do you make BibLaTeX do it?

>> And there are quite a few people who /do/ care about
>> the references. For instance, I work for a journal,
>> where we (with a friend of mine) are responsible for
>> (among others) typesetting the papers. We sometimes
>> spend/waste quite a lot of time on bibliographies
>> (mainly because authors "don't care" - if they
>> actually used BibTeX and not hand-crafted,
>> inconsistent formatting, things would be a lot
>> easier for us...). I even wrote an Emacs utility
>> which helps transform such inconsistent pile of s##t
>> into proper markup.
>
> Of course references should be correct and consistent
> and software (including Emacs modes) should support
> it. I think BibLaTeX does its job and the problem (?)
> with lack of support for "national hyphenation" isn't
> anything I would ever worry about.

Well, as I mentioned earlier, I do worry about it, working for a journal
which is typeset in Polish, but the articles often quote other works,
mainly in English, but sometimes in German, French or Russian. Happily,
we don't use BibLaTeX, but amsrefs, which happens to support
multi-language bibliograhic entries. In this department BibLaTeX does
/not/ do its job, period. And hyphenation is just the symptom, not the
disease; the disease is that some language-dependent conventions are
hard-wired into the software. (I guess that this exchange helped /me/
understand the reason for my strong negative feelings for BibLaTeX: as
a (professional) mathematician and a (hobby) programmer, I can't stand
when a theorem/program is not general enough when it should be. Thank
you, Emanuel!!!)

[Emanuel Berg]

Marcin Borkowski <mb...@mbork.pl> writes:

> If by "typography" you mean "putting all the
> elements where the designer wants them to be" - then
> I agree (to some extent - try using LaTeX to typeset
> anything containing equations /and/ figures on the
> grid, or to wrap a figure with text when the text
> includes an enumeration - good luck!) that it's
> /relatively/ simple (at least most of the time).
>
> If by "typography" you mean "the art and technique
> of arranging type to make written language readable
> and appealing" (this is what Wikipedia has), then
> you most probably need /at least/ half a dozen years
> to get reasonable experience, and twice to three
> times that to achive what could be called mastery.

You can have a look at my Master paper. It has a ToC,
footnotes, references, an index, figures, tables,
lists, definition boxes, equations, inline code (the
appendix - even an inline man page!), and more.

http://user.it.uu.se/~embe8573/hs-linux/docs/report/report.pdf

I spent many hours on the LaTeX, of course, but I'm
a layman. If I ever were to write something more for
the techno-scientific world, I'd just reuse 95+% of
the stuff because I'm already happy with it. The last
couple of per cent I'd keep for unexpected events, but
it's possible it'd be more like 99-1 or 100-0
depending on the project.

We should remember that techno-science writing has
a much bigger need for all those tables and lists and
all that than ordinary books, like travel writing or
sports commentary or whatever. Because the contents is
much more complicated, it is necessary to do.
Without it, I could easily have written 200-300 pages
and not the ~150 it turned out to be. Also, the
logical and structured contents is easily reflected in
a logical and structured report. It is natural as well
as beneficial to do, not only to the report but to the
implementation as well.

On the other hand, if I had a publishing house that
published crime and science fiction novels and travel
books and all that it would be absolutely no problem
to get one or two or three books to look good and then
just use them as blueprints to mass produce books.

I'm sure a "Master" at typo-whatever would be able to
typeset my paper better, but by how much? I don't
think the difference would have been radical even in
"absolute terms", and as for the presumed reader
experience, I think it would have been minimal. Here,
feel free to check it out, that'd be interesting to
hear...

And, the Master-layman difference - both aspects -
would be yet much smaller (infinitely so) for
ordinary books.

Normal books aren't flawlessly typesetted or
well-organized, all of them, even from the grand old
houses. Many of them lacks and index or a nested ToC,
many of them have notes (the commented ones, which you
want to read, not the references) - many have them as
a separate part at the back so you have to turn back
and forth all the time, and many have references bulky
right in the text instead of the discrete [9] system.

So no, I don't believe it is something only masters of
the lost art can do. I expect them to be better than
me but not to a degree that will have any
significance. I can typeset a brand-new Stephen King
novel every day of the week and master or not (i.e.,
not) it'd sell like sliced bread just the same.

That said, I think it is absolutely fascinating and
fun to do, and I did it very seriously indeed just as
I think it should because it really makes
a difference, so I'm not disrespectful in that way,
rather I think it can be done and then mass production
can take on, and you don't have to worry about it or
spend a lifetime mastering it.

And when it comes to writing that should explain or
document things, I think it is more a challenge to see
what is a list, what is a table, what can be made into
a figure, what are the keywords that should be
defined, all that - after that, making it so with
LaTeX is straightforward (and fun) and if you get
stuck just ask at comp.text.tex :)

> If you're wondering what the publishing houses do
> all day, I can tell you what. I work for a small
> journal (two issues per year, each issue is
> typically 150-200 pages long), and it's /a lot/ of
> work. I work there with a friend, and our duties are
> (mainly) to, let's call it, "make the issue look
> good". We receive the files prepared by the authors,
> and after several weeks of hard work we produce
> a pdf file ready to send to the printing house.
> And by hard work I mean hard work - probably the
> main reason it's just "hard" and not "impossible" is
> several thousand hours of experience of both of us.
> (Another reason is that I have a few hundred lines
> of Elisp code, automating these parts of our job
> that /can/ be automated - it's not even a majority,
> but it saves us considerable time of boring,
> repetitive tasks.)

Again, I don't see how that cannot be solved by
reusing the LaTeX from last issue? I already said all
the stuff I did and modified or just put there to
varying degrees. Most or all of that stuff would
reoccur if I ever did it again. So I'd just use it all
over but with new material. It would require some
fiddling and some fixed detail but it cannot be
compared by far with the original work, that'd be like
100-1 in man hours. And for every iteration such
overhead would get smaller as experience is gained...

> What does it have to do with BibLaTeX? Exactly what
> I wrote about: different countries (or cultures)
> have different naming schemes, and BibLaTeX supports
> only a small subset of the set of Germanic naming
> schemes. No Slavic ones (granted, the Polish one is
> trivial, especially now that it's simplified: even
> though we don't have any von-like thing, we did have
> declension of names depending on sex, and for female
> names also on the marital status: the wife of Mr.
> Nowak used to be called Nowakowa, and his daughter -
> Nowakówna. These forms, however, are very seldom
> used now. AFAIK, in Czech you still have something
> like this), no Asian ones, no Icelandic ones. (I
> don't know about other languages.)

All people have names, at least since the paleo-Romans
who assigned numbers to their daughters (first,
second, etc. in the order they were born). And that's
all it takes (names). The ethnic traditions and their
implications (?) doesn't break the association that is
desired in this case, which is between the work and
them who did it.

[Emanuel Berg]

Emanuel Berg <embe...@student.uu.se> writes:

> You can have a look at my Master paper. It has
> a ToC, footnotes, references, an index, figures,
> tables, lists, definition boxes, equations, inline
> code (the appendix - even an inline man page!),
> and more.
>
> http://user.it.uu.se/~embe8573/hs-linux/docs/report/report.pdf

Oh, I'll put this here as well. Here is all source -
if you search the directories and subdirectories - the
LaTeX, BibLaTeX, groff, gnuplot, pic(1), as well as
Makefiles to automatize everything.

If you are a student or for some other reason do this,
and you have the same taste as me, feel free to use
whatever. That will save you many hours...

http://user.it.uu.se/~embe8573/hs-linux/docs/